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

[Alexander Leidinger]

Am 2024-01-30 10:42, schrieb Luca Pizzamiglio:

Hi Alexander.

Subpackage modularization of existing ports (i.e. qt6-tools) provides benefits to package users/builders: smaller dependency footprint, smaller usage on disk (useful for embedded systems), smaller jails. There are no benefits nor regressions for port builders for this specific use case.

Nicely worded. I agree to that. At the same time it is a regression for port builders. Installing from ports is not on par with installing from pkg anymore in this case. What you describe means we can use subpackages only for leaf ports. Ports which are a dependency can not converted to subpackages (in the sense of "no slave port available for the subpackages").

On the other hand, moving master/slave ports to subpackages comes with the cost of losing the ability to build the slave ports independently. For package users there is no change and some benefit for package builders. The issue can be mitigated by introducing options to select which subpackage to build (available for make install as well), but, still, a single subpackage cannot be built independently.

This is not a proper mitigation. I used mail/roundcube and lang/php as a specific example for this particular case where it is not a proper mitigation.

This limitation _can_ be unacceptable in some cases. For example, bofh@, the php maintainer, considers subpackages not the way to go, so the master/slave approach will stay.

Do you see that you just told that one of the best role models for subpackages according to you previous mail will not use subpackages because of the limitations I highlighted?

We introduced subpackages in the framework to explore all use cases, by trying and testing its adoption. By doing so we have already identified some issues (i.e. USES is not subpackage-aware yet) and interesting new use cases (subpackage with debug symbols).

You are surely aware that you haven't mentioned one of the points I talked about as an issue, don't you? I have not seen any technical answer which shows that my technical description of issues is wrong. I want to make you aware that I understand the responses from you and the others in this thread as: "we do not care about those regressions and do not want to fix them" (I understand it like that because I see no acknowledgement of those issues, just answers which look like a smokescreen and pointing into directions of good faith). If you would acknowledge the technical issues highlighted in this thread (or show evidence that those regressions can not happen) and tell that the adoption of subpackages is monitored to not introduce those regressions I talk about, my understanding of the situation would change.

As per master/slave merge use case, we will let the maintainers decide if they want to move forward with subpackage adoptions, knowing the regression for port builders, but we won't push them in this direction.

Bye,
Alexander.

I consider it unfortunate that you describe it like that. I was hoping you would tell that portmgr will prevent the removal of slave packages and enforce the rule of having slave ports for subpackages aware ports to prevent regressions for users which install from ports (until the technical valid issues I have pointed out are resolved -- and they can be fixed, a first step would be to make the names of subpackages match normal packages names = replacing the '~' in the name with a '-' ASAP to prevent churn later). Note, in src some big discussion like this of having several committers identify regressions and no immediate fix would lead to a backout until it is fixed. I do not ask for a backout of this, but I ask for a strong lock/policy by portmgr on the subpackages feature like I already described in my previous mails (until the regressions the use of subpackages would create are fixed). This would allow for more experimentation by a lot of people without the need to patch the ports tree and without introducing regressions for a simple "make install" of ports with a lot of dependencies.

Best regards,
Luca

On Mon, Jan 29, 2024 at 10:04 AM Alexander Leidinger <alexan...@leidinger.net> wrote:

Am 2024-01-27 16:59, schrieb Luca Pizzamiglio:

Hi Stefan.



Subpackages is a feature to create multiple packages from one build
Those subpackages can depend on the main package.
The main package cannot depend on any subpackages.
This limits the cases where subpackages can be applied. The main

add features (like a plugin).
To recall your NLS example (ref

Let's start from the beginning, as it seems that things are not clear. package MUST be independent from its subpackages. Subpackages can only https://reviews.freebsd.org/D16457#715443): this is not a use-case for

subpackages. If the main program/library needs to be compiled
differently with or without NLS, this is not viable for subpackages.
If a port needs to be built multiple times to create different
subpackages, this is not a viable case for subpackages.
A good candidate is qt6-tools: this port contains multiple tools
(designer, linguist, help, and so on). Those tools could be put in
different subpackages.

I hope this explanation helps to clarify and address some of your
concerns.

has a benefit (in the sense it matches your description above to the

build as subpackages is a plugin/extension).

As I read this, lang/php is the best example of a port where subpackages letter, the main port independent from the subpacakges, and what can be

OPTIONS and SUBPACKAGES
Do we have to convert OPTIONS to SUBPACKAGES? No.
Can a SUBPACKAGE be built only if an OPTION is enabled? Yes.
The only viable use cases for SUBPACKAGES being enabled/disabled by

main package.
Examples are: additional libraries, additional data files, and so on.

Consolidate master/slave ports in one bigger ports

explosion of build time of the consolidated ports.
This is a justified concern.

enabled via OPTIONS.
This will allow port builders to configure the bigger ports to not
build all SUBPACKAGES, but only the needed ones. This should restore
the previous build time.

However, as for the php case, the maintainer is going to evaluate if
the consolidation makes sense or not.

it can be reverted and subpackages not adopted for the use case.

OPTIONS is limited to those portions of the port that do not affect the About this topic, I guess your concerns are mainly related to potential In those cases, we are suggesting to convert slave ports in SUBPACKAGES If a consolidation is going to result more problematic than beneficial,

slave ports and to use subpackages instead (where this makes sense in
terms of the current implementation of subpackages). Or worded

the intention), when someone converts a port to subpackages, the
corresponding slave packages shall be removed (or for new ports: slave
ports shall not be introduced in this case).


when installing from ports, as the subpackages can not be targeted for
install directly and my example of a subpackages aware php results in

via make install in /usr/ports/something/with_webinterface. -> best

in our ports collection.


can not depend on subpacakges for "make install", and as if the port
would be converted to have subpackages but no slave ports are
introduced, pkg install and make install would differ in the amount of
installed files.

If I understand the sum of all the above correct, you suggest to remove differently to the same effect (as I only care about the effect and not Removing slave ports means we can not depend upon specific parts anymore security implications of to much being installed and active if installed example of lang/php to use subpacakges is the best example of why not to use subpackages / shows what is a regression in the features we provide While qt6-tools may be a good example where subpackages makes sense, we

For port builders

Port builders can experience longer build times in the future, as
master/slave ports could be consolidated in one single larger ports.
If this is the case, the larger ports should provide OPTIONS to not
build unneeded subpackages.

one.

If no OPTION is available, please work with the maintainer to introduce

I fail to see the benefit:

ports are removed / not introduced) on make install (with a similar
amount of build time for the ports tree as it is right now), or get
higher build times for the package builders. In both cases we do not
gain something significant.

If we want to keep the (useful in some cases) feature to install from
ports (there is the case of py39-rpds-py failing to build in my

runtime issue in maturin, which shows up in my the cross build on
amd64-intel for amd64-athlon64... which in the end leads me to build

of subpackages has to come with the requirement to create slave ports
for each subpackage.

That's my concern, and that's the reason why I have the opinion, that
portmgr has to keep the lock on subpackages and reject any subpackage
which don't come with a slave port.


install (an implementation could be to require "make install
TARGET_SUBPACAKGES=sub1,sub2,sub3" or "make install-subpackage1
install-subpacakge2"... as long as recursive dependencies are handled

reviewing this can argue about such details).

Keeping the current implementation (with the restriction of always
introducing slave packages for subpackages) would need a way to denote

builders to skip those slave ports (and the subpacakges would need to
have the same package name as the slave port, no idea if this has a
technical disadvantage in terms of having 2 different origins for the

look).

TLDR: for the use cases you specified in the beginning, I do not see a

or "build time reduction for package builders" (which would have a
benefit for a lot of use cases) is in my books much more in the

modularization of qt6-tools)?

Bye,
Alexander.

--

We either lose the possibility to target parts of a package (when slave poudriere which I tried to debug with the author of py-maturin due to a py-rpds-py on the target machine from ports), the current implementation I would be OK to lift this restriction, when the current implementation is changed to be able to only install the files of a subpacakge on make according to this requirement, those people designing, implementing and that a slave port covers a specific subpackage which would allow package same package name, but it surely would be confusing for people at first benefit, only drawbacks. Can you please provide an example of a benefit I fail to see (yes, more modularity for qt6-tools may be beneficial for some people, but the cost/benefit between qt6-tools (something which we don't provide right now) and "make install" (what we provide right now) direction of "make install" and "build time reduction" than towards the http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF

signature.asc
Description: OpenPGP digital signature