Re: Subpackage explanations

Luca Pizzamiglio <pizzamig@freebsd.org> writes:

> The first use case we want to get rid of is master/slave ports when slave
> ports could be built with the master port.

Could doesn't necessarily mean should. For example, merging
gimp-jxl-plugin back into libjxl would increase build time and risk of
"missing packages" due to larger dependency chain in a port used by
many directly and even more indirectly.

> 2. the build is going to change the configuration of appstream, enabling
> the compose OPTION, to build the dependency.

Known limitation even without subpackages e.g.,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247517
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251855
https://lists.freebsd.org/pipermail/freebsd-ports/2005-August/025244.html

Gentoo shows how such support may look like e.g.,
https://devmanual.gentoo.org/general-concepts/dependencies/#built-with-use-dependencies

> * all options enabling subpkg has to be ON by default, to not introduce
> broken dependencies

Often already done as "batteries included" even without subpackages.

> * we encourage to limit the introduction of those optional subpackages,
> limiting their adoption only for cases where the related subpackage adds a
> relevant set of dependencies

Removing options is a POLA violation, so this may hinder subpackages
adoption. What was supposed to be a mechanical change ends up requiring
deeper insight into all possible use cases for a given port.