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 _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"