Design for Flavors and Sub Packages
Design
Common needs
- bapt: I will make pkg able to read a manifest which instead of being a ucl object will be an array of ucl object in this case it will generate multiple packages
- bapt: add a keyword @pkg[name] something in plist, the content will be added to the package named "name"
Flavors
One port is built multiple time with variations, each variation creating a separate package. For example, python 2/python 3, or minimal / normal / huge options.
The code for the FLAVORS is in https://reviews.freebsd.org/D10327
A bad example of how to convert PYTHON to it is available in https://reviews.freebsd.org/D12464
Some helpers https://reviews.freebsd.org/D12483
Before commit:
Fix this patch to support the *:ORIGIN@FLAVOR dependency line syntax (many of the *-depends targets don't know how to handle that)
Decide on a sub-package dependency line syntax to ensure it does not conflict with "origin@FLAVOR,subpackage"
Announce intentions to community (first 2 items need solved first because people will want to test and see a working patch)
Make a wiki page for FLAVORS design (needed for tools developers) Flavors Tools
Add helpers for PKGNAMEPREFIX/SUFFIX, and CONFLICTS*
- Figure out how OPTIONS + FLAVORS work. Meaning if we make bash-static into a FLAVOR, how do I change the OPTIONS only for FLAVOR=static *as a user*? I can do that now, but it's not possible with this patch. We need to modify the OPTIONSFILE (sp?) to include FLAVOR and do something about make config, etc. This is also likely a lacking feature in Poudriere to properly these options.
PORTS_FEATURES+=FLAVORS
PKG_NOTES support (see comments)
Add a hook preventing adding FLAVORS without portmgr's approval
Anytime:
Release Poudriere 3.2
Disallow FLAVORS having 'all' and silently discard FLAVOR=all
Make a wiki page for FLAVORS conversion (like the STAGEDIR one): Flavors Migration
- Document that FLAVORS may need to define CONFLICTS on each others PKGNAMES if they conflict with each other
portsmon / FreshPorts support
Decide if MOVED should support @FLAVOR syntax. I think it should since we'll want to do things like move shells/bash-static to shells/bash@static. (Poudriere will have implicit support for this)
Document that each FLAVOR must have a unique PKGNAME, there is a qa check for that
Make qa or sanity-check enforce that each FLAVOR has a unique PKGNAME
Make helpers -- not sure on specifics -- but at least one for CONFLICTS -- probably one for easily mapping directly to one or more options in OPTIONS_DEFINE and making them default
- Document some policy on NOT effectively doing FLAVORS=${OPTIONS_DEFINE} - this will be highly subjective as to what is acceptable and not but is why we have the 6 month window to come up with this policy
- Enforce in sanity-check that _DEPENDS_ARGS_ and _FLAVOR_ are not both defined (this is a saving grace for things like Poudriere to not blow up wildly)
Sub Packages
Build the port once and create multiple packages. For example, have a sub package for docs and examples.
Tools
The build tools will need to be made aware of the fact that an origin will generate more than one package
poudriere
Done, use poudriere-devel-3.1.99.20170621 or newer
If you run poudriere bulk some/port@all that has flavors, all flavors will be built. poudriere bulk some/port will build the default flavor.
If you need to test a non default flavor, run poudriere testport some/port@flavor
portmaster
Portmaster has been updated to support flavors in December of 2017.
Flavors are selected in the same way in poudriere (some/port@flavor), but building all flavors of a port (some/port@all) is not supported (since portmaster is not used to create a repository for later installation, but installs all ports it builds).
portupgrade
Not done, bdrewery@ will publish what needs to be done if someone is interested in doing it.