Date: Sun, 17 Dec 2017 09:46:44 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: Stefan Esser <se@freebsd.org>, FreeBSD Ports ML <freebsd-ports@freebsd.org> Cc: FreeBSD Port-Manager <portmgr@FreeBSD.org> Subject: Re: Can we have multiple flavors for a port? Message-ID: <98b88bc3-a4c1-bc1a-528e-612ed060cef6@FreeBSD.org> In-Reply-To: <09760447-455d-5de0-36a9-c978d84cfb72@freebsd.org> References: <6ed4ac6e-a075-0fc0-a3da-371a46a9e977@FreeBSD.org> <09760447-455d-5de0-36a9-c978d84cfb72@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) --sBFlrFoAijXmn17bsOandV1KQ1CFgeCpU Content-Type: multipart/mixed; boundary="n7OFfsmfQG26ispn5W4EbMh69dGFW1EVO"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: Stefan Esser <se@freebsd.org>, FreeBSD Ports ML <freebsd-ports@freebsd.org> Cc: FreeBSD Port-Manager <portmgr@FreeBSD.org> Message-ID: <98b88bc3-a4c1-bc1a-528e-612ed060cef6@FreeBSD.org> Subject: Re: Can we have multiple flavors for a port? References: <6ed4ac6e-a075-0fc0-a3da-371a46a9e977@FreeBSD.org> <09760447-455d-5de0-36a9-c978d84cfb72@freebsd.org> In-Reply-To: <09760447-455d-5de0-36a9-c978d84cfb72@freebsd.org> --n7OFfsmfQG26ispn5W4EbMh69dGFW1EVO Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 16/12/2017 14:24, Stefan Esser wrote: > Am 16.12.17 um 14:51 schrieb Matthew Seaman: >> >> I have a review up to add a USES=3Ddjango -- >> https://reviews.freebsd.org/D12592 which I'm now modifying to be FLAVO= RS >> compatible given that has hit the tree. >> >> Now, we currently have ports for 4 different versions of django (1.8, >> 1.10, 1.11, 2.0) and the obvious next move is to add django-based >> flavouring. Currently, most django ports depend on django-1.8, with a= >> few depending on django-1.10, but this I think is mostly due to inerti= a >> and django ports should be compatible with more recent versions. Havi= ng >> four different versions of django in ports seems excessive -- so, for >> the sake of argument I'd cut that down to just django-1.11 and django-= 2.0 >> >> But this is all python code, and the python flavouring would also appl= y... >> >> Given that django-2.0 requires python-3.5+ we end up with the followin= g >> combinations: >> >> py27 django111 >> py36 django111 >> py36 django20 >> >> and there's some 104 django ports which will mostly end up needing all= >> three of these variants built -- so as combinatorial explosions go, it= 's >> not particularly earth-shattering. >> >> However, my questions are: >> >> - Is it possible or desirable to have multiple flavourings like this= ? >> >> - If so, what should the syntax look like for specifying a particula= r >> combination? eg. www/py-django-mezzanine@py27+django111 ? >=20 > I asked portmgr@ the same question when I started to work on portmaster= > and did not want to implement a solution that does only support a singl= e > flavor per port (or rather, waste time and effort on a portmaster versi= on > that only supported 1 flavor per port, when there were plans to support= > multiple flavors in the ports framework in the future). >=20 > The answer I received was very clear: There can only be 1 flavor per po= rt > and there are no plans to remove that restriction. >=20 > I questioned the wise-ness of that decision, but had better use for my > time than to continue arguing, that multi-flavor support was probably > going to be required very soon. >=20 >=20 > My questions were specifically, how a dependency with multiple flavors > should be specified (e.g. "@py36@xyz") and how to query a port for this= > case. The same notation should be used in the MOVED file in such a case= =2E >=20 > The order of flavors added to an origin must either be ignored by all > tools operating on them (which precludes simple string comparisons to > see whether one origin+flavors is identical to another one) or should > be required to follow some (e.g.) lexical order. >=20 >=20 > I'd also like to see the flavor(s) (if any) become part of the port ori= gin > (or some other variable in the PKG DB that can easily be queried). The > value should be identical to the format in dependencies and the MOVED > file to simplify tools like portmaster, which currently must execute a > complex series of queries to get at that information. Heh. I wrote the package annotation functionality, but I never anticipated the way that it has come to be used. I just thought of it as a way for package builders and end users to add notes to their package database, with no real functional effect. Instead, now it's being used as the quick and simple way to add novel metadata to packages, and to affect the way pkg(8) goes about solving dependency chai= ns. I have some mixed feelings about this. We used to have significant database schema churn whenever some metadata change happened in pkg(8), which made upgrading pkg(8) a bit more risky and harder to back-out than ideal. Now though, you can just create an annotation. No low-level schema change needed. On the other hand, you can't use pkg-query(8) or pkg-rquery(8) or similar to select and display packages according to the new metadata items like flavor. > The origin@flavor does not encode the information previously contained > in just the origin. >=20 >=20 > IMHO, multi-flavor support should have been one of the initial consider= ations > when designing the flavor extension to the ports system! Hmmm... There is another consideration here. Most of the django stuff I'm looking at is pure python code, and not dependent on against linkage to any specific shared library. Which means that the packages for the different flavours would be basically identical except for the metadata tracking the dependency chain. Making a raft of such similar packages, replicating the package file content each time strikes me as wasteful of time and resources. Why can't we express the alternate possibilities in the package metadata and have one package that fits all cases? I recall a proposal about "variable dependencies" being discussed at BSDCan a few years back -- is this anywhere on the roadmap? Potentially this would apply to many of the packages for interpreted or byte-compiled languages in the tree -- so Perl, Ruby, PHP, Java and in principle Python, although that has been complicated by the incompatible changes involved between python-2.7 and python-3.x. Cheers, Matthew --n7OFfsmfQG26ispn5W4EbMh69dGFW1EVO-- --sBFlrFoAijXmn17bsOandV1KQ1CFgeCpU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKoBAEBCgCSFiEEGfFU7L8RLlBUTj8wAFE/EOCp5OcFAlo2PQVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDE5 RjE1NEVDQkYxMTJFNTA1NDRFM0YzMDAwNTEzRjEwRTBBOUU0RTcUHG1hdHRoZXdA ZnJlZWJzZC5vcmcACgkQAFE/EOCp5Oegew/+I4Zya6dbHOouBvoRV/SJ+6jfxQWO 1zAH72+P9Y273xfmPjQYz9+uln3P6QBn4qzVZaOsg+diff/+oFUuhWaPaqNn0QyJ QDDD5RvF1G2Qs14j8XT3h72X1hVpRNVP4Vz/yghv8ETJpPUOcgIExQrfgY0yMU5a /bigTqmHr0mT3KYybbNwqQOFJH2iPXKqy1CQ/rdLFLkX7ah60AhVtR7dWUGvTPd6 ussgFif8Lj0BqIztoazo8NkQH1Gzdk5cCvh6pr6/8uq57ZWeiZDwgeAVYhDwJ2dl 1MfkQCJwFwvmsv/h44mOpbMmfCTMwBt7R6Uu62Z0aHBCjLalTlocy98v4sgCctfo zHY+BzUG0+FyYwVl9QPqqk9ZWsWQWPjvP9pBrrxJe+MlXHvhag2hqNdvVIDISqTW NzLM763uyZtZDGFmbwP6d0XLu9JqEmX8A6zsG9HGF4sczyMqz9dGJqGI8mhm59Cm uEsDjGEs69unAXoWpwanUenR8iFzNuJ7YPaEFAdIREKHNdvd9ggxioV3zUpBon3I 4m81hlHUY5mupqZFIX3mospFShCvLDpCaSyrtS37H9wreZObO9qLSmoSNi6/RcG2 MmYASsziCBcixj43b1lQDEjl3g4QHERdyhinr/HzCLnnJ+QZY2f+Qw5432UlTxN5 NQ+xP9yn67hg0/A= =Kp7g -----END PGP SIGNATURE----- --sBFlrFoAijXmn17bsOandV1KQ1CFgeCpU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98b88bc3-a4c1-bc1a-528e-612ed060cef6>