Date: Sat, 4 Jun 2022 13:40:33 +0200 From: Stefan Esser <se@FreeBSD.org> To: koobs@FreeBSD.org Cc: freebsd-ports <ports@freebsd.org>, python <python@FreeBSD.org>, Tatsuki Makino <tatsuki_makino@hotmail.com>, Chris <portmaster@bsdforge.com> Subject: Re: unknown flavor py37 Message-ID: <6e363656-99b1-b0a0-846e-954738a0febc@FreeBSD.org> In-Reply-To: <97e227bf-09f9-c563-6626-9354c49fca64@FreeBSD.org> 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> <97e227bf-09f9-c563-6626-9354c49fca64@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------J8dgen6lBgQJ5OmSgKPX28mC Content-Type: multipart/mixed; boundary="------------ixYcimHWmIq7jMuntW8fEjA0"; protected-headers="v1" From: Stefan Esser <se@FreeBSD.org> To: koobs@FreeBSD.org Cc: freebsd-ports <ports@freebsd.org>, python <python@FreeBSD.org>, Tatsuki Makino <tatsuki_makino@hotmail.com>, Chris <portmaster@bsdforge.com> Message-ID: <6e363656-99b1-b0a0-846e-954738a0febc@FreeBSD.org> Subject: Re: unknown flavor py37 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> <97e227bf-09f9-c563-6626-9354c49fca64@FreeBSD.org> In-Reply-To: <97e227bf-09f9-c563-6626-9354c49fca64@FreeBSD.org> --------------ixYcimHWmIq7jMuntW8fEjA0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 04.06.22 um 01:02 schrieb Kubilay Kocak: > BUILD_ALL_PYTHON_FLAVORS was implemented in the reverse of what it shou= ld have > been (DONT_BUILD_ALL_PYTHON_FLAVORS or other). >=20 > It was implemented ostensibly as a convenience for poudriere, such that= the > default was for poudriere *not* build all possible supported Python pac= kage > 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: >=20 > 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 bu= ilds any > supported, available or installed Python version, derived as the inters= ection > of the ports USES=3Dpython:<version-spec>, DEFAULT_VERSION value, and w= hat 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 purpose= s. > 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 whe= n ports > supported Python versions were a *superset* of their underlying depende= nts > 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 sup= ported > Python versions. >=20 > 3) A substantial reduction in the UX, and increase in the support overh= ead, for > Python packaging and use on FreeBSD, examples being the "errors" above.= >=20 > What needs to happen from here: >=20 > - 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 provide= d as packages. > - Poudriere needs the ability to only build a single flavor package (no= t 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_versi= on), 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 poudri= ere except for pre-commit testing of port changes, but I'm still affected by = the FLAVOR issues.) --------------ixYcimHWmIq7jMuntW8fEjA0-- --------------J8dgen6lBgQJ5OmSgKPX28mC Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmKbRLIFAwAAAAAACgkQR+u171r99UTr bggAw1m2HLFdj381sLNPhYa3JPDOlzLxFxkXxv7jynY6YliD8k5CnwgcUT52lBpWFu8UlIvl7I/y a1w5Id53aQWKAVZrtWRcGEU3VrSwBgOr+jqyFB81al6gDltFCRb6Ihw9eA96pdtigw/z1le7Ehwl h09/+Jnr7XeqswTVLzix1haf+wbwZfU9zRuItcO8XSuN5Ut8I1Js1lM21x5vyC0AqGMB0E3fRmO9 /5nOsBIFzmAdVPsNPNy+s03unplrQbp4+dnDSQ3tLzBLecFHAvmbrOli79XamIGCZjteO5xg8OSZ srYk6CADIF4fqjA126nYYg/CmKEkBFg1Fn/au3MoyA== =501U -----END PGP SIGNATURE----- --------------J8dgen6lBgQJ5OmSgKPX28mC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6e363656-99b1-b0a0-846e-954738a0febc>