Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] multiversion ebuilds
Date: Wed, 16 May 2018 07:38:41
In Reply to: [gentoo-dev] [RFC] multiversion ebuilds by Gerion Entrup
W dniu sob, 12.05.2018 o godzinie 14∶20 +0200, użytkownik Gerion Entrup
> Hi, > > just an idea for now. But what you think about multiversion ebuilds? > Technically this could be realized with the following line in the ebuild itself: > ``` > VERSIONS=( 3.0.11 3.0.12 3.1 ) > ``` > > and the filename without version: > <dev-category>/<package-name>/<package-name>.ebuild > > together with this set of rules: > 1. If there is an ebuild with had a version in its name, this ebuild is preferred. > e.g. is a tree consists of "foobar/foobar-1.1.ebuild" and "foobar/foobar.ebuild" for version 1.1 the specific ebuild is taken. > 2. If the ebuild has the variable VERSIONS specified but also a version in its name, the version in its name is taken. > 3. There can be only one multiversioned ebuild per package. > > Different version keywording can be done as before: > ``` > if [[ ${PV} == "3.1" ]] ; then > KEYWORDS="~amd64 ~x86" > else > KEYWORDS="amd64 x86" > fi > ``` > > The resolution of versions can be done as before, with the difference that one ebuild can represent multiple versions. > > The "ebuild" tool needs some adjustments. Maybe it tries to download and build all version per default and has an additional flag to specify a single version. > > The advantages of this idea I see are: > - Ebuilds are written in a multiversion manner anyway, and then get copied (or linked?), so it can be made explicit. > - The diffs between different versions of ebuilds and the commit history are way more readable. > - The size of the tree reduces. >
In my opinion, this puts more effort into inventing a problem than solving one. In order to consider a particular idea thouroughly, you should also consider potential disadvantages, rather than focusing purely on advantages as you see them. While one might think that this will help developers, it is going to be a maintenance nightmare. Just compare the workflow. Currently, adding a patch affecting runtime involves copying the ebuild, and applying the patch. Later on, the old revision is just removed. With your solution, you need to adjust VERSIONS, add conditional; later on, you need to adjust VERSIONS, find all conditionals, remove them. Not only it involves more work but also increases the risk of accidental breakage. The arch team work is going to become a nightmare. Currently, they just use 'ekeyword' tool to mass-edit ebuilds. With your solution, they're now have to find the correct conditional (or add one), and update keywords there. I can already imagine monsters like: if pv1; then KEYWORDS="~amd64" elif pv2; then KEYWORDS="amd64 ~arm64 x86" elif pv3; then KEYWORDS="~amd64 ~arm64 ~x86" elif pv4; then KEYWORDS="amd64 ~arm64 ~x86" fi Basically, any action requiring >1 arch team would involve creating a new version at least temporarily. And I seriously doubt arch teams would really want to spend time collapsing those afterwards. The algorithm you presented might look nice at first. But remember that the developers will now have to do the same thing -- i.e. discover which ebuild should they look at. You're moving for a clear 1 ebuild : 1 file mapping to N ebuilds : 1 file. -- Best regards, Michał Górny


Subject Author
Re: [gentoo-dev] [RFC] multiversion ebuilds R0b0t1 <r030t1@×××××.com>
Re: [gentoo-dev] [RFC] multiversion ebuilds Gerion Entrup <gerion.entrup@×××××.de>