Why portmaster try to install python 3.6 when I have 3.4 set in /etc/make.conf?

[Stefan Esser]

Am 10.01.18 um 23:56 schrieb Jim Trigg:
> ISTR that there is a more generic variable that will cause make to work with
> all flavors instead of the default "common" set. Not where I can easily look
> up specifics right now...

FLAVOR support has many rough edges and I expect those to hurt us in one way
or the other in the future. A lot of them could easily be fixed, but a sound
design should have covered them from the beginning.

There is no generic ALL_FLAVORS variable, but some of the generic FLAVOR
support implemented in Mk/Uses does offer a way to access all FLAVORs. In the
case of Python ports, you have to pass -D BUILD_ALL_PYTHON_FLAVORS to make to
get FLAVOR set to all supported Python versions/flavors:

$ make -V FLAVORS
 py27 py36

$ make -V FLAVORS -D BUILD_ALL_PYTHON_FLAVORS
py27 py36 py35 py34

The upcoming Emacs flavor support will use a different parameter and for any
of the many individual ports, that support flavors directly in their
respective Makefiles, the variable will have a local name.

There seems to be a clear opinion in the portmgr team, that not all flavors
of each port shall be built by the package build cluster, but only those that
are most commonly used (e.g. py27 and py36), which I understand because else
there would be thousands of additional python packages (and later perl and
others) that are hardly ever used. But there should still be provisions to
obtain a full list of flavors in a generic way. (I had used "FLAVORS" to
denote a list of all supported flavors and e.g. PKG_FLAVORS for those that
are selected for the package builders, but FLAVORS for the selected set and
ALL_FLAVORS for the complete set will do as well ...)

I'm not going to work-around such deficiencies in the design of FLAVORs in
portmaster. I'd have to follow each new port that is converted to flavors to
check whether it has all flavors in FLAVORS and which other name it uses for
a list of possible FLAVOR values (if such a list explicitly exists at all,
it could also be implicitly present in the form of control structures in the
port's Makefile).

I'll ask portmgr for a few small changes (a generic ALL_FLAVORS variable and
a make target that lists all package names and corresponding flavors for a
port), and I hope I get approval for these changes.

For now I'll have to develop a method that at least partially compensates the
missing FLAVOR support features required for port management tools.

Regards, STefan