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
>>>> 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
> 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
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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"