HEADSUP: FLAVORS (initial version) and subpackages proposals

[Miroslav Lachman]

Baptiste Daroussin wrote on 2016/12/22 21:08:
> On Mon, Dec 19, 2016 at 07:12:02PM +0100, Miroslav Lachman wrote:
>> Matthew Seaman wrote on 2016/12/19 09:45:
>>> On 19/12/2016 07:47, David Demelier wrote:
>>>>> I have been working for a while on 2 long standing feature request for the ports
>>>>> tree: flavors and subpackages.
>>>>>
>>>>> For flavors I would like to propose a simple approach first which is more like a
>>>>> rework of the slave ports for now:
>>>>>
>>>>> Examples available here:
>>>>> https://reviews.freebsd.org/D8840 (with the implementation)
>>>>> and
>>>>> https://reviews.freebsd.org/D8843
>>>>>
>>>>> Design: introduce a 3rd level in the hierarchy and make it work a bit like slave
>>>>> ports
>>>>>
>>>>> pros:
>>>>> - all slave ports are self hosted under the same directory: easier for
>>>>>     maintenance
>>>>> - should work with all existing tools
>>>>>
>>>> This is what I really wanted for years especially for ports like spell
>>>> checker. Some are in dedicated categories such as french/aspell while
>>>> other are in textproc/<lang>-aspell and that's a big mess.
>>>>
>>>> OpenBSD ports has something like textproc/aspell/<lang> and that is
>>>> very nice and clean. If the plan is to do the same, that is definitely
>>>> a major improvement.
>>>>
>>>
>>> I really like this idea, although it's going to add a lot of extra
>>> directories and very similar small Makefiles to the ports.  Every python
>>> port would grow flavours to support two major versions of python just
>>> for starters, and those additional Makefiles would be almost identical
>>> across the python2 flavour and across the python3 flavour.
>>
>> Can this be processed by some code in Mk/bsd.*.mk?
>> I mean if we can add something to the main Makefile then we don't need to
>> add subdirectories and sub-Makefiles for each Python module port.
>
> If we do that we do break the paradigm: 1 package = 1 origin which will break
> portmaster/portupgrade for example

But we don't have that now. For example dns/py-dnspython can create 
py27-dnspython, py33-dnspython, py34-dnspython, py35-dnspython - four 
different packages from one origin, one Makefile.
OK, I noticed now that slave port for py3 was added "recently" but even 
this slave port can create 3 different packages according to what 
default version of python 3 is installed.

Another thing is that portmaster and portupgrade are not well maintained 
and I think ports / ports framework evolution should not be slowed down 
because of "3rd party" utilities. Or we will end up with adding tons of 
directories and small files just to create endless pile of slave ports.

Miroslav Lachman