Date: Mon, 29 Jan 2024 10:03:36 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Luca Pizzamiglio <pizzamig@freebsd.org> Cc: Stefan Esser <se@freebsd.org>, FreeBSD ports <freebsd-ports@freebsd.org>, portmgr <portmgr@freebsd.org>, FreeBSD Core Team <core@freebsd.org> Subject: Re: This is going to break port building without poudriere! Message-ID: <1e27bce44f2ba85f0097fbc6aba1dac1@Leidinger.net> In-Reply-To: <CAB88xy-AkwJWhUtdfjernOumzshahJ_KRH1wOqRROceFbq3=GA@mail.gmail.com> References: <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com> <cd0c0cb0-6035-45b4-b3e8-d99115e6c013@FreeBSD.org> <CAB88xy8gTC4UJK0fOiHnVCFf0AGtLoHfHdOAF29zChQ8=5SV6w@mail.gmail.com> <609374cf-7f1f-4643-8379-f368b23ccb09@freebsd.org> <CAB88xy-AkwJWhUtdfjernOumzshahJ_KRH1wOqRROceFbq3=GA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_95f53f3a767db87175f0df71c3b4cb37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-01-27 16:59, schrieb Luca Pizzamiglio: > Hi Stefan. > > Let's start from the beginning, as it seems that things are not clear. > > 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 > package MUST be independent from its subpackages. Subpackages can only > add features (like a plugin). > To recall your NLS example (ref > 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. As I read this, lang/php is the best example of a port where subpackages has a benefit (in the sense it matches your description above to the letter, the main port independent from the subpacakges, and what can be build as subpackages is a plugin/extension). > 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 > OPTIONS is limited to those portions of the port that do not affect the > main package. > Examples are: additional libraries, additional data files, and so on. > > Consolidate master/slave ports in one bigger ports > About this topic, I guess your concerns are mainly related to potential > explosion of build time of the consolidated ports. > This is a justified concern. > In those cases, we are suggesting to convert slave ports in SUBPACKAGES > 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. > If a consolidation is going to result more problematic than beneficial, > it can be reverted and subpackages not adopted for the use case. If I understand the sum of all the above correct, you suggest to remove slave ports and to use subpackages instead (where this makes sense in terms of the current implementation of subpackages). Or worded differently to the same effect (as I only care about the effect and not 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). Removing slave ports means we can not depend upon specific parts anymore when installing from ports, as the subpackages can not be targeted for install directly and my example of a subpackages aware php results in security implications of to much being installed and active if installed via make install in /usr/ports/something/with_webinterface. -> best 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 in our ports collection. While qt6-tools may be a good example where subpackages makes sense, we 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. > 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. > If no OPTION is available, please work with the maintainer to introduce > one. I fail to see the benefit: We either lose the possibility to target parts of a package (when slave 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 poudriere which I tried to debug with the author of py-maturin due to a 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 py-rpds-py on the target machine from ports), the current implementation 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. 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 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 according to this requirement, those people designing, implementing and 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 that a slave port covers a specific subpackage which would allow package 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 same package name, but it surely would be confusing for people at first look). TLDR: for the use cases you specified in the beginning, I do not see a 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) 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 direction of "make install" and "build time reduction" than towards the modularization of qt6-tools)? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_95f53f3a767db87175f0df71c3b4cb37 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmW3afgACgkQEg2wmwP4 2IbpORAAnteg1C5NU7Fhcj7ndTq7oZWx7DAiPVr6qokyT+btJGpKhThaLB+n4Xm1 NYCf0gMfNcKCht8uWuejG+eIZkVN7Sou+wyZbQ7Ey07vWVCAV1bu/MENzwAzHaBU gZYs11626G1ZdyBCGX2XgyqzyxOSEJjk3c/A8ulB7C9TyLdxWf7q5dxlggwodfAV PAbfW5J/HuvIBLL6q9fVNuGpqafsH/vyQVtsMdtBF5r/A6B5J8ZsijBYaNjx8h85 95yDC1EUp68AdH0OXZbyU0PdP0p4HAb6tClC8TzQmSWX5RpptmMNQoK2MxarTL9u WRfLRBHxajOe2yDjPn6gCs0N8vztQJ616Xfec0XInrXqWcW0Vkwus9YJiHmtkmrV u823YsKiHcF3ceTyhoZy6wP32W5Exi9h2kE7YGJo7CrfCn1GB8vVGnZ4tnm8CCdh QkeESgW4aLmiXihreCIDKz9RYcnOajCFN+wPoe+fK06BWZvRb8AK0QQ0Q7iQm+xd XF9tdBeFKM8TWFP+LLQTN7tl3ppqIq7YLBmf5dkMiSLwHut6gStQo4PN3Q3OLA2d Z0vejL6eE7WBixOlFw3RXtaFznb2tL20xJIGm/WOprGQ3c46pFa6duCzKTQPH/iz ozvFf/t347gAxEXq2JDTowmzoY+lm9tW5kVYHly/O6ABgNAJmdY= =wRzG -----END PGP SIGNATURE----- --=_95f53f3a767db87175f0df71c3b4cb37--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1e27bce44f2ba85f0097fbc6aba1dac1>