Julian Elischer julian at freebsd.org
Wed Sep 27 11:53:11 UTC 2017

On 27/9/17 4:20 pm, Matthew Seaman wrote:

Before this gets too far down the road I would like to suggest that we 
quickly formalise some nomenclature
or we will have 200 different ideas as to how to do the same thing;

I would like to propose the following possible "examples of official" 
-nodocs         ..  nearly every port has a DOCS option..  a way to 
automatically turn it off globally and generate said pkgs would be good.
-minimal ..  smallest possible feature set.. probably used just to 
satisfy some stupid dependency.
-kitchensink    ..  speaks for itself .. options lit up like a 
christmas tree
-runtime        ..  no .a files, include files, development 
documentation or sources ..
                     might only contain a single libxx.so.N file, or a 
single binary executable.

Other suggestions welcome. These were just suggestions. I await your 
suggestions with interest.

I would certainly like the 'runtime' version as that would allow me to 
create packages for, and populate appliances.

A ports developer would be encouraged to supply as many of the 
official flavours as make sense.
Poudrierre could be taught to generate only "minimal" packages etc.

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

More information about the freebsd-ports mailing list