Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jan 2024 13:13:31 +0100
From:      Jan Beich <jbeich@FreeBSD.org>
To:        Luca Pizzamiglio <pizzamig@freebsd.org>
Cc:        FreeBSD Ports mailing list <freebsd-ports@freebsd.org>, freebsd-ports <ports@freebsd.org>
Subject:   Re: Subpackage explanations
Message-ID:  <sf2l-8vbo-wny@FreeBSD.org>
In-Reply-To: <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com> (Luca Pizzamiglio's message of "Wed, 24 Jan 2024 10:28:48 %2B0100")
References:  <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sf2l-8vbo-wny>