Re: This is going to break port building without poudriere!

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