Am 24.01.24 um 10:28 schrieb Luca Pizzamiglio:
Hi porters!
At the beginning of January, we merged the support to subpackages in the
framework.
Subpackage is the feature to create multiple packages from one build of one
port. In other words, now it's possible to group files into multiple packages.
This means that from one port it's possible to split the build into several
packages.
Some additional details are available in this lighting talk at EuroBSD 2023
(https://youtu.be/e-FUYbGNdBg?t=824 <https://youtu.be/e-FUYbGNdBg?t=824>).
Hi Luca,
you did not reply to my mail regarding the many issues of this approach
to sub-packages, which I had previously stated as a comment to the review
your commit is based on:
https://reviews.freebsd.org/D16457#715443
This comment has been ignored for more than 2 years, and my attempt to
have PortMgr consider a better approach has been ignored.
This implementation will break port dependencies, since there is no way
a port can depend on a specific sub-package - there even is no way a
non-default sub-package can be built without manual selection of the
options that activate its creation.
Dependencies stated in the port Makefile are converted into package
dependencies that can be resolved by the "pkg" command, but that cannot
be directly used to build and install the requested sub-package from
a port.
Has there been a general consensus that support for direct port building
(without poudriere) will be abandoned?
Ports that do not create sub-packages can still be depended on by other
ports, but as critical dependencies have been depended to sub-packages
a ever large fraction of ports will only build in poudriere.
This change does also obviously break port management tools like portmaster,
which took me significant effort to adapt to FLAVOR support (which also had
been implemented without consideration for other tools than poudriere), and
which I have been maintaining since then.
The reason given for sub-packages support is reduced build time for some
packages that share a common distfile (e.g. qt5) when building official
packages.
But this comes at a high cost for all builds outside the package build
cluster, since now lots of unnecessary sub-trees will be compiled and
installed, if only one program (i.e. sub-package) is desired.
You are pessimizing the build for thousands of users to spare a few
cycles for a very small percentage of packages built once in a while on
the build cluster.
I had pointed out other issues with this approach in the review comment
and in the private mail I sent 2024-01-02 after finding that this version
has been committed without formal acceptance of your review D40549.
You are breaking use-cases of a large number of users that still build
ports without poudriere. This is especially causing a barrier to entry
of new port developers, since this will require them to setup poudriere
before they can begin port development. (This will only become an issue
over time, as more and more dependencies will have been converted to
sub-packages, but then there will be no way back.)
Your announcement mentions some of the issues, but does not offer any
actual solution.
A sane implementation of sub-packages would not make their creation
depend on OPTION settings, with no way to determine the required OPTION
setting for a non-default sub-package (i.e., only default sub-packages
can be depended on).
I'm not going to repeat all the issues pointed out in
https://reviews.freebsd.org/D16457#715443
but had on multiple occasions pointed out that a sane mechanism would
start with "SUB_PACKAGE_DEFINE" and "SUB_PACKAGE_DEFAULT" variables and
with a mechanism to determine the required OPTION values from the actual
set of sub-packages to be built (instead of the opposite, to make the
selection of sub-packages depend on the OPTIONs).
As with FLAVORs, an implementation has been committed that lacks design
and does not even attempt to support use-cases other than package building
with poudriere.
