Date: Wed, 27 Sep 2017 19:52:54 +0800 From: Julian Elischer <julian@freebsd.org> To: Matthew Seaman <matthew@FreeBSD.org>, freebsd-ports@freebsd.org Subject: Re: [HEADUP] FLAVORS landing. Message-ID: <91d1252c-5398-dca8-f337-959fa722efc7@freebsd.org> In-Reply-To: <e7cfc564-3c59-e21d-2586-89436a3abb38@FreeBSD.org> References: <dcc6fa75-8325-01e9-4a86-e3bc61bb27a2@FreeBSD.org> <b964b742-389d-a4e6-0f5f-f30f976d79bd@freebsd.org> <a236f275-4cff-72d1-7d90-955a43062458@FreeBSD.org> <c7e8a348-0b17-d5e8-bf8d-e499c813f8d7@arved.at> <e7cfc564-3c59-e21d-2586-89436a3abb38@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91d1252c-5398-dca8-f337-959fa722efc7>