Re: unknown flavor py37

On 2022-06-04 04:40, Stefan Esser wrote:
> 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.)
IMHO you really hit the target here in your reply, Stephan. As a maintainer I
have found FLAVORS in it's current state to be as frustrating as helpful. 
Thanks
for your thorough evaluation of this Kubilay.

Chris