On Mon, 19 Dec 2016 01:31:43 +0100 Baptiste Daroussin <[email protected]> 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 <[email protected]>
pgpKyNhOOomNS.pgp
Description: OpenPGP digital signature
