Date: Fri, 01 Dec 2017 18:43:34 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 224024] DEFAULT_VERSIONS for python and PYTHON_VERSION broken after r455210 (FLAVORS) Message-ID: <bug-224024-21822@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224024 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 python 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= python=3.6 python2=2.7 python3=3.6 % cd /usr/ports/devel/py-pandas % make -V FLAVOR % make PYTHON_VERSION=python3.4 -V FLAVOR Expected behavior % make -V FLAVOR py36 % make PYTHON_VERSION=python3.4 -V FLAVOR py34 Observed behavior % make -V FLAVOR py27 % make PYTHON_VERSION=python3.4 -V FLAVOR py27 -- You are receiving this mail because: You are on the CC list for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224024-21822>