[Bug 224024] DEFAULT_VERSIONS for python and PYTHON_VERSION broken after r455210 (FLAVORS)

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Dec 1 18:43:34 UTC 2017


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 at FreeBSD.org
          Reporter: john at saltant.com
                CC: freebsd-ports-bugs at FreeBSD.org, python at 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.


More information about the freebsd-ports-bugs mailing list