Date: Thu, 25 Jan 2024 14:18:52 +0100 From: Stefan Esser <se@FreeBSD.org> To: Luca Pizzamiglio <pizzamig@freebsd.org> Cc: freebsd-ports <ports@freebsd.org>, portmgr <portmgr@FreeBSD.org>, FreeBSD Core Team <core@freebsd.org> Subject: This is going to break port building without poudriere! (was: Subpackage explanations) Message-ID: <cd0c0cb0-6035-45b4-b3e8-d99115e6c013@FreeBSD.org> In-Reply-To: <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com> References: <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd0c0cb0-6035-45b4-b3e8-d99115e6c013>