Date: Wed, 27 Sep 2017 09:20:05 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-ports@freebsd.org Subject: Re: [HEADUP] FLAVORS landing. Message-ID: <e7cfc564-3c59-e21d-2586-89436a3abb38@FreeBSD.org> In-Reply-To: <c7e8a348-0b17-d5e8-bf8d-e499c813f8d7@arved.at> References: <dcc6fa75-8325-01e9-4a86-e3bc61bb27a2@FreeBSD.org> <b964b742-389d-a4e6-0f5f-f30f976d79bd@freebsd.org> <a236f275-4cff-72d1-7d90-955a43062458@FreeBSD.org> <c7e8a348-0b17-d5e8-bf8d-e499c813f8d7@arved.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/09/2017 08:09, Tilman Keskinöz wrote: > > > On 2017-09-27 08:29, Matthew Seaman wrote: >> On 27/09/2017 07:11, Julian Elischer wrote: >>> Is there a document/paper on what this is and what it's limits are etc? >> >> https://wiki.freebsd.org/Ports/FlavorsAndSubPackages >> https://wiki.freebsd.org/Ports/FlavorsMigration >> > > These pages don't contain any information what this is, how it differs > from/interacts with the OPTIONS framework and why I would want to > convert a port to FLAVORS. Well, you can think of FLAVORS as essentially a group of different pre-sets for OPTIONS or DEFAULT_VALUE settings, so you can build several different instances of the same port with different configurations easily. It has the biggest benefit for people either using the default pkg repositories or who are building their own via poudriere or similar. Currently the idea is to work on the python ports in the tree so we'd have both python-2.7 and python-3.6 versions built and available in the repos. That's just the initial target to debug and bed-in the FLAVORS stuff. This will all need to interact with two other changes due to hit the tree in the not too distant future: sub-packages --- so from one WRKSRC you can generate several different packages. eg. separate packages for doc or examples, a shlibs package, a devel package with eg. static libraries and headers, a debug package with separate files for the debugging symbols, as well as the main package with the principal binaries and so forth. So, for php, it's going to make a big change. Instead of extracting the entire PHP sources and building each PHP module as a separate job, all of the PHP modules for a particular version of PHP could be built at once, and the results just assigned to different packages. variable-dependencies --- this should remove one of the biggest frustrations with the packaging system at the moment, where dependences are very strict and pkg(8) will insist on installing exactly the version of any dependencies a package was compiled against. Frequently this is unnecessary, as the same package should work fine with eg. a later version of a dependency, or with an alternate implementation (eg. mysql vs mariadb). Overall, it means the repositories will end up containing more packages, but these will generally be smaller and allow finer grained control of what gets installed on your system. The downside at the moment is that tools like portmaster are pretty much tied to the idea that there is a 1-to-1 relationship between ports and packages, which this definitively breaks. Cheers, Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7cfc564-3c59-e21d-2586-89436a3abb38>