HEADSUP: FLAVORS (initial version) and subpackages proposals

[Matthieu Volat]

On Mon, 19 Dec 2016 01:31:43 +0100
Baptiste Daroussin <bapt at FreeBSD.org> wrote:

> Hi all,
> 
> 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
> 
> cons:
> - hackish: it is not really much more than a slave port
> - it adds plenty of new Makefiles :(
> 
> I think anyway this is an improvement
> 
> Next step after that is in would be to extend it to allow some dependency on "I
> depend on whatever flavor if port X"
> 
> Subpackages:
> Design:
> Add a new macro MULTI_PACKAGES
> flag plist with an @pkg{suffixofthesubpackage} file
> the framework will split the plist into small plist and create all the packages
> All variables like COMMENT can be overridden with a COMMENT_${suffixofthesubpackage}
> 
> pros:
> - simple and working almost now
> - allow to simplify lots of ports
> - options friendly (<optionname>_PACKAGE automatically appends a new entry to
>   MULTI_PACKAGES)
> 
> cons:
> - will break the paradigm that certain tools depend on (portmaster/portupgrade
>   in particular are a huge problem since they are not actively maintained)
> 
> Example of the usage:
> https://people.freebsd.org/~bapt/multipackage.diff
> 
> Note that I took the mpg123 as an example because it was a simple one to test
> not because it may need subpackages
> 
> As a result you build 3 packages:
> mpg123 (the runtime tools)
> mpg123-lib: the runtime libraries
> mpg123-sndio: the sndio plugin
> 
> LIB_DEPENDS on ports depending on libmpg123.so does not have to be changed, the
> framework already automatically register only the mpg123-lib as a dependency and
> not others.
> 
> Not the example is missing one thing: a dependency between mpeg123-lib and
> mpg123
> 
> The second is not ready yet and would take time to land
> 
> Any comment?
> 
> Best regards,
> Bapt

Does this approach would manage a file that differ between flavors? Let's say there a libfoo.so file that behave differently wheter an option A is selected or not, but is still present in both cases. 

On another note, I kinda liked the macports approach to use the "+" separator regarding naming flavors/options, it allows to better distinguish what in the package name and what are the selected options, and handled itself quite well with multiple instances, like "vim+nls+python+x11"... Did you consider something like that?


-- 
Matthieu Volat <mazhe at alkumuna.eu>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20161219/847301d1/attachment.sig>