Date: Thu, 22 Dec 2016 21:12:14 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Matthieu Volat <mazhe@alkumuna.eu> Cc: ports@FreeBSD.org Subject: Re: HEADSUP: FLAVORS (initial version) and subpackages proposals Message-ID: <20161222201214.w52whr2xoex5wijf@ivaldir.etoilebsd.net> In-Reply-To: <20161219202536.2d0a1955@freedom.alkumuna.eu> References: <20161219003143.c2qo5wn3a5kiua3m@ivaldir.etoilebsd.net> <20161219202536.2d0a1955@freedom.alkumuna.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
--mxnbrb2czp4dlm4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2016 at 08:25:36PM +0100, Matthieu Volat wrote: > On Mon, 19 Dec 2016 01:31:43 +0100 > Baptiste Daroussin <bapt@FreeBSD.org> wrote: >=20 > > Hi all, > >=20 > > I have been working for a while on 2 long standing feature request for = the ports > > tree: flavors and subpackages. > >=20 > > For flavors I would like to propose a simple approach first which is mo= re like a > > rework of the slave ports for now: > >=20 > > Examples available here: > > https://reviews.freebsd.org/D8840 (with the implementation) > > and > > https://reviews.freebsd.org/D8843 > >=20 > > Design: introduce a 3rd level in the hierarchy and make it work a bit l= ike slave > > ports > >=20 > > pros: > > - all slave ports are self hosted under the same directory: easier for > > maintenance > > - should work with all existing tools > >=20 > > cons: > > - hackish: it is not really much more than a slave port > > - it adds plenty of new Makefiles :( > >=20 > > I think anyway this is an improvement > >=20 > > Next step after that is in would be to extend it to allow some dependen= cy on "I > > depend on whatever flavor if port X" > >=20 > > 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_${suffixoft= hesubpackage} > >=20 > > pros: > > - simple and working almost now > > - allow to simplify lots of ports > > - options friendly (<optionname>_PACKAGE automatically appends a new en= try to > > MULTI_PACKAGES) > >=20 > > cons: > > - will break the paradigm that certain tools depend on (portmaster/port= upgrade > > in particular are a huge problem since they are not actively maintain= ed) > >=20 > > Example of the usage: > > https://people.freebsd.org/~bapt/multipackage.diff > >=20 > > Note that I took the mpg123 as an example because it was a simple one t= o test > > not because it may need subpackages > >=20 > > As a result you build 3 packages: > > mpg123 (the runtime tools) > > mpg123-lib: the runtime libraries > > mpg123-sndio: the sndio plugin > >=20 > > LIB_DEPENDS on ports depending on libmpg123.so does not have to be chan= ged, the > > framework already automatically register only the mpg123-lib as a depen= dency and > > not others. > >=20 > > Not the example is missing one thing: a dependency between mpeg123-lib = and > > mpg123 > >=20 > > The second is not ready yet and would take time to land > >=20 > > Any comment? > >=20 > > Best regards, > > Bapt >=20 > 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 s= elected or not, but is still present in both cases.=20 Yes >=20 > On another note, I kinda liked the macports approach to use the "+" separ= ator 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 co= nsider something like that? No because, actually there were some ports doing that in the past. and we removed that because it makes it hard to identify programatically packages Also not that the information about the options used are already stored in = the package and pkg can show them to you Best regards, Bapt --mxnbrb2czp4dlm4c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlhcM54ACgkQY4mL3PG3 Plo8rg/+Klugs+lmfeeltJuN5lFqIQfXm6kv6Ttp3Nua6xfkdPbzl9cAPbG4OcKZ T7X+to9jRibxMtoZcmMCNG+UYovGOTt93Xv8IRjIGyGS5Lx2NJUDGP7iLfrb2VlV X+WCubaaCjXl+yskoBXKphbaQuouOxMYKlSvCgVTYBenODkLiSwn9WzOiuTB0EuS 5qn7D7OzMaVdbBRWroABselhoqwjPEKiEzs5MSh2RsZ+WGt4zA9awFz4bNX8webJ 3WXvKnTfX9BYJGlHNaPBSbG4eXLab6aQriLgdp8GzI6RCzXhEJ+BTLfUw+16nUNw 4x0EWg2s7LsRmzXcDfKISt5SvYk9Xk/odvgF9I9HauAZ0Kg+hYhKFNMARJ0eSIvd yDmun8VhCNQwcswFX26bbc/dad2goBArAZJMC6G2veE83ZhfTm0ZHUTE8XstynD2 ANdsRmcSBaJ6PupLT7XkqQMDZGpPqOrbWEgV1puIcNdsAYuj4c9PQUYXvvCrs/8d 206uFDybF/NMdsqdUeL57GdlF+y1zfF4fQNe8gg79aAv8ktjI7KG7WRudYQhwd2R szaUjF/uIdRWA6RNa+qnOiS/D86wdyVrJWiyD9+zE+QIKLKWT1LkXnYq8209Ec6A zSs1mliv+T9zeeFECiJhkZb6ogC+MIXq9N6EGMxI2Z4MZ2pc3JE= =wHwE -----END PGP SIGNATURE----- --mxnbrb2czp4dlm4c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161222201214.w52whr2xoex5wijf>