On 12/10/2016 8:12 PM, Matthew Seaman wrote: > On 2016/10/12 09:43, Kubilay Kocak wrote: >>> You are describing the 'sub-packages' concept that has been >>> knocking >>>> around for some time. With sub-packages you'ld divide up the >>>> result of staging each port into various chunks: >> Yep, like this: >> >> Mar 6 2016 - https://reviews.freebsd.org/D5563 Ports framework >> "variants" proof-of-concept (with poudriere support) >> >> Status Report Dec 2015 - Supporting Variants in the Ports >> Framework >> >> https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Supporting-Variants-in-the-Ports-Framework > >> > Variants is a related but different concept -- known as 'flavours' > (or 'flavors') in some parts. The difference is that 'sub packages' > divide up the output from one compilation of the sources, whereas > 'variants' or 'flavours' require the same source code to be > recompiled with different options. (As you'ld need to do to create > eg. py27- and py34- versions of python modules.) Both are things we'd > like to have in ports, but they can be implemented pretty much > separately.
They could be, but they don't need to be. From one perspective, division of a port (or package) is exactly a 'variant'. Yes a 'part' (-debug package) of a whole (-full package) is a "sub package", but the 'debug' variant of the foo port only includes debug files, and has a -debug suffix. Variants (in its current PoC form) is just a generic implementation for enabling one-to-many-packages, and is not prescriptive. The 'what to Vary: on' (like the HTTP headers), including perhaps what to include or exclude from the package, is left as a exercise for the configuration, or portmgr or a later stage discussion. There is nothing explicitly prescribing that specified 'variants' must compile source each time (or do anything else specific for that matter), or that said variants cannot merely execute the "dividing up" (on some basis) logic on the resulting artifacts that were created in the common/base 'variant'. > 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"
