Date: Fri, 01 Dec 2017 18:43:34 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 224024] DEFAULT_VERSIONS for python and PYTHON_VERSION broken after r455210 (FLAVORS) Message-ID: <bug-224024-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224024 Bug ID: 224024 Summary: DEFAULT_VERSIONS for python and PYTHON_VERSION broken after r455210 (FLAVORS) Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Ports Framework Assignee: portmgr@FreeBSD.org Reporter: john@saltant.com CC: freebsd-ports-bugs@FreeBSD.org, python@FreeBSD.org My goal I want to build and manage packages in the spirit of PEP 394, so that I can maintain concurrent installs of ports for any combination of supported pyth= on versions, one of which may be for the default python version, one of which = may be for the default python2 version, and one of which may be for the default python3 version. In the past, I have accomplished this by setting DEFAULT_VERSIONS in /usr/local/etc/poudriere.d/make.conf, and then setting PYTHON_VERSION in each of /usr/local/etc/poudriere.d/pythonXY-make.conf for= XY in {27,34,35,36}. This yields four different repositories with packages that can, generally speaking, be installed concurrently. Problem This technique stopped working after FLAVORS were introduced in r455210. To demonstrate % cat /etc/make.conf DEFAULT_VERSIONS=3D python=3D3.6 python2=3D2.7 python3=3D3.6 % cd /usr/ports/devel/py-pandas % make -V FLAVOR % make PYTHON_VERSION=3Dpython3.4 -V FLAVOR Expected behavior % make -V FLAVOR py36 % make PYTHON_VERSION=3Dpython3.4 -V FLAVOR py34 Observed behavior % make -V FLAVOR py27 % make PYTHON_VERSION=3Dpython3.4 -V FLAVOR py27 --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224024-13>