Can we have multiple flavors for a port?
matthew at FreeBSD.org
Sun Dec 17 09:46:48 UTC 2017
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=django --
>> https://reviews.freebsd.org/D12592 which I'm now modifying to be FLAVORS
>> 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 inertia
>> and django ports should be compatible with more recent versions. Having
>> 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 apply...
>> Given that django-2.0 requires python-3.5+ we end up with the following
>> 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 particular
>> combination? eg. www/py-django-mezzanine at py27+django111 ?
> 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 single
> flavor per port (or rather, waste time and effort on a portmaster version
> that only supported 1 flavor per port, when there were plans to support
> multiple flavors in the ports framework in the future).
> The answer I received was very clear: There can only be 1 flavor per port
> and there are no plans to remove that restriction.
> 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.
> My questions were specifically, how a dependency with multiple flavors
> should be specified (e.g. "@py36 at xyz") and how to query a port for this
> case. The same notation should be used in the MOVED file in such a case.
> 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.
> I'd also like to see the flavor(s) (if any) become part of the port origin
> (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 chains.
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 at flavor does not encode the information previously contained
> in just the origin.
> IMHO, multi-flavor support should have been one of the initial considerations
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 992 bytes
Desc: OpenPGP digital signature
More information about the freebsd-ports