Date: Sat, 4 Jun 2022 09:02:18 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: Tatsuki Makino <tatsuki_makino@hotmail.com>, Chris <portmaster@bsdforge.com> Cc: freebsd-ports <ports@freebsd.org>, python <python@FreeBSD.org> Subject: Re: unknown flavor py37 Message-ID: <97e227bf-09f9-c563-6626-9354c49fca64@FreeBSD.org> In-Reply-To: <PSAPR03MB5639A140A1B66ABD509470D1FAA19@PSAPR03MB5639.apcprd03.prod.outlook.com> References: <2A99B1E9-BAEC-463D-B933-1ED5F09763E5@cs.huji.ac.il> <E6710DAA-21D2-49DE-B3B8-ED379CBA3948@FreeBSD.org> <73DBCA36-27D4-4BF0-9D04-D859316D0C8E@cs.huji.ac.il> <PSAPR03MB563975478E1D3D2A3EE77DDCFAD99@PSAPR03MB5639.apcprd03.prod.outlook.com> <dda51a029296d966bdf9fe34318687a0@bsdforge.com> <350ac74130b6aa98eaed716a3b5e9679@bsdforge.com> <PSAPR03MB5639A140A1B66ABD509470D1FAA19@PSAPR03MB5639.apcprd03.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97e227bf-09f9-c563-6626-9354c49fca64>