Re: This is going to break port building without poudriere!
Date: Thu, 25 Jan 2024 18:10:24 UTC
On 1/25/24 08:18, Stefan Esser wrote: > 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, > [...] > 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. Stefan, many thanks here from one devoted portmaster user! > > [...] > 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. Perhaps it's time for a new public FreeBSD mailing list: freebsd-disruptive-changes-coming-ready-or-not@freebsd.org so more people will have a chance to comment and contribute before any hard-to-reverse steps are taken. -- George