[HEADUP] FLAVORS landing.
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
-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?
>> 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
> 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.
> freebsd-ports at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports