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

Am 2024-01-26 12:12, schrieb Luca Pizzamiglio:

> Hi Alexander.
> 
> You understand correctly what I wrote:
> * Several master/slave ports can be converted to use subpackages.
> * Php is a potential candidate for subpackage adoption
> However, I wasn't explicit on the fact that I won't impose subpackages 
> adoption on anyone.
> Specifically, I don't want to convert php into subpackages right away, 
> there are smaller/easier examples to tackle first.

Thanks for confirming. IMO you overlook the fact that there may be 
people eager to convert to subpackages. If we would adopt the policy to 
provide -lib ports, I would jump on converting audio/lame to a libraries 
and frontend subpackages aware port. Some stuff only needs the lib and 
not the frontend. It may be a small change for the ports collection, not 
relevant for the ports build cluster, not relevant for all users, but I 
would do it quickly. I'm also looking forward for debug-symbopls 
packages. I think this is a very nice and good idea and would ease some 
cases where I was spending time to rebuild packages with debug symbols 
to find the cause of issues. So what you have is a good first step, but 
in the current state requires strong governance in my point of view. 
More below.

> And in general, the maintainer is the one making the decision, and they 
> can disagree with me.
> An experimental adoption will be considered for lang/php83, existing 
> versions won't be converted.

php82 was simply a specifc example, there are surely other ports which 
fall into the same case. I don't mind to convert existing stuff to 
subpackages, if there is no discrepancy between "make install" and "pkg 
install". I would even think it would be a good idea to convert from a 
global point of view, it could cut down the build time on my poudriere 
instance.

> As you pointed out, there are two challenges specifically for php:
> * moving all extensions (slave ports) to subpackages in lang/php* can 
> significantly increase build times (for ports users) and its dependency 
> list (for pkg users)

The dependency list for pkg users would stay the same, wouldn't it? The 
amount of dependencies for a given port doesn't change, only the origin. 
If phpXX-zip is available as a subpackage, the origin doesn't matter. 
But if a port install also installs phpXX-xml together with phpXX-zip if 
it has the same origin, but php-XX-xml is not in the dependency list, 
that would be a severe regression as it may have security implications 
(again, just an example what can happen, but one example which we need 
to take into account while thinking about subpackages).

> * the meta php-extensions port is a convenient way create a custom 
> group of extensions
> Php port could be converted into subpackages if and only if we can 
> provide a similar experience as before.
> To do that:
> * we would need to add options to enable/disable extensions, in order 
> to manage build times and dependencies

I would rather describe this part as "being able to depend on a specific 
subpackage and not the complete origin in make based port installs" to 
have a converted lang/phpXX not install more dependencies for 
mail/roundcube on make install.

> * we need to provide the similar meta php-extensions package, as it's 
> largely used
> 
> If the maintainer finds out that subpackages are not suitable for php, 
> they won't be adopted.

The concept of subpackages is IMO suitable for php. I fear that there is 
a faster adoption of this feature than you want to advocate for. That's 
the reason why I think that the current implementation should keep the 
apporval-lock by portmgr, and a veto from portmgr for ports where the 
change to subpackages would results in a change of the origin of the 
dependencies (with lang/phpXX as a prominent and best example of what I 
mean with that). And this veto should be kept until the subpackages 
implementation allows to have "make install" and "pkg install" result in 
only the minimal dependencies being installed (= until the missing 
feature you talked about above is implemented in a way that make install 
in mail/roundube only installs those php extensions it requires).

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF