Can we have multiple flavors for a port?

Stefan Esser se at freebsd.org
Sat Dec 16 14:27:01 UTC 2017


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
> 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 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.

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!

Regards, STefan


More information about the freebsd-ports mailing list