Re: unknown flavor py37

Am 04.06.22 um 01:02 schrieb Kubilay Kocak:
> BUILD_ALL_PYTHON_FLAVORS was implemented in the reverse of what it should have
> been (DONT_BUILD_ALL_PYTHON_FLAVORS or other).
> 
> It was implemented ostensibly as a convenience for poudriere, such that the
> default was for poudriere *not* build all possible supported Python package
> flavours.

This has bothered me for a long time, too. And it is a problem not only
for the Python ports.

IMHO there should have been FLAVORS (covering all availble flavors) and
e.g. DEFAULT_FLAVORS meant to contain the subset selected for official
packages.

But there should not have been a limit on what flavor is available when
building a port (as long as the selected port can work with that flavor).

> The net effect however, was/is:
> 
> 1) The burden implicitly shifted to everyone else needing to opt into
> BUILD_ALL_PYTHON_FLAVORS, when the default ought to have been a port builds any
> supported, available or installed Python version, derived as the intersection
> of the ports USES=python:<version-spec>, DEFAULT_VERSION value, and what a user
> has installed, if any any.

I could live with an ALL_FLAVORS variable to generally list all flavors
for all flavored ports (often identical to FLAVORS). Then FLAVORS could
keep its role of controlling the selection for the package builders, and
ALL_FLAVORS could be used to identify valid flavors for all other purposes.

> 2) It forced ports to depend on and match, *exactly*, the <version-spec> of all
> of their dependencies, otherwise causing "bulk -a" errors [1], even when ports
> supported Python versions were a *superset* of their underlying dependents
> supported versions. This resulted in Python ports <version-specs> being
> incorrectly updated [1], limiting user choice of Python version support,
> reversing a goal and progress the Python team has had to more correctly,
> completely and declaratively, and eventually automatically, specify supported
> Python versions.
> 
> 3) A substantial reduction in the UX, and increase in the support overhead, for
> Python packaging and use on FreeBSD, examples being the "errors" above.
> 
> What needs to happen from here:
> 
> - The BUILD_ALL_PYTHON_FLAVORS option needs to go away. Before that can happen...

Yes, and as explained above, I'd really like to have FLAVORS always cover
all supported flavors, and a new macro like DEFAULT_FLAVORS (or any other
name that is then used by the package builders) for the selection provided
as packages.

> - Poudriere needs the ability to only build a single flavor package (not all
> flavors) without requiring the ports default to be only one. This might take
> the form of some notion of 'default flavor' (derived from default_version), or
> something else.

I thought that this was already the case?

At least when building a port on the base system ... (I do not use poudriere
except for pre-commit testing of port changes, but I'm still affected by the
FLAVOR issues.)