Design for Flavors and Sub Packages


Common needs


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

A bad example of how to convert PYTHON to it is available in

Some helpers

Before commit:

  1. Fix this patch to support the *:ORIGIN@FLAVOR dependency line syntax (many of the *-depends targets don't know how to handle that)

  2. Decide on a sub-package dependency line syntax to ensure it does not conflict with "origin@FLAVOR,subpackage"

  3. Announce intentions to community (first 2 items need solved first because people will want to test and see a working patch)

  4. Make a wiki page for FLAVORS design (needed for tools developers) Flavors Tools


  6. 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.

  8. PKG_NOTES support (see comments)

  9. Add a hook preventing adding FLAVORS without portmgr's approval


  1. Release Poudriere 3.2

  2. Disallow FLAVORS having 'all' and silently discard FLAVOR=all

  3. Make a wiki page for FLAVORS conversion (like the STAGEDIR one): Flavors Migration

  4. Document that FLAVORS may need to define CONFLICTS on each others PKGNAMES if they conflict with each other
  5. portsmon / FreshPorts support

  6. 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)

  7. Document that each FLAVOR must have a unique PKGNAME, there is a qa check for that

  8. Make qa or sanity-check enforce that each FLAVOR has a unique PKGNAME

  9. 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

  10. 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
  11. 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.


The build tools will need to be made aware of the fact that an origin will generate more than one package


Done, use poudriere-devel- 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 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).


Not done, bdrewery@ will publish what needs to be done if someone is interested in doing it.

Ports/FlavorsAndSubPackages (last edited 2022-04-20T11:08:32+0000 by StefanEsser)