[HEADUP] FLAVORS landing.

[Matthew Seaman]

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