On 3/06/2022 2:42 pm, Tatsuki Makino wrote:
Sorry, this email was delivered to my junk folder.
I just pulled this up now :)
Chris wrote on 2022/05/28 14:25:
I just bumped into this problem after checking out a fresh ports tree and
building
a port that dependant on devel/py-doit. It complained much the same as above.
required
my performing the build with:
$ make -DBUILD_ALL_PYTHON_FLAVORS ...
So this just seems wrong. python-37 was already installed and is also still
present
in a current version of the ports tree. I know some recent changes were made in
ports/Mk
and I think something may have not been changed correctly.
Just thought I'd mention it.
Chris
Some py-* ports may be USES=python:3.8+, so such ports will fail FLAVOR=py37.
devel/py-doit fails because it has USES=python:3.8+.
FLAVOR=py37 of multimedia/openshot
env BUILD_ALL_PYTHON_FLAVORS=1 make -C /usr/ports/multimedia/openshot
FLAVOR=py37 build
cannot get to the point of starting the build because devel/py-qt5-pyqt has
USES=python:3.8+.
Regards.
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.
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.
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...
- 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.
Python is happy to help figure out a good way forward on this.
- Python ports should not be required to limit or change their supported
Python version <version-specs>, to incorrect or unnecessarily
constrained values in order to 'unbreak bulk -a' [1].
bulk -a or the underlying dependency resolution mechanism or metadata
(in ports, poudriere, or both), should be fixed/improved.
Again, Python is happy to help figure out a good way forward on this.
[1] https://cgit.freebsd.org/ports/log/?qt=grep&q=unbreak+bulk
