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