Re: [gentoo-dev] [RFC] multiversion ebuilds

[Gerion Entrup]

Am Mittwoch, 16. Mai 2018, 09:38:30 CEST schrieb Michał Górny:
> W dniu sob, 12.05.2018 o godzinie 14∶20 +0200, użytkownik Gerion Entrup
> napisał:
> > 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.
I'm not sure, if I understand you correctly, so I try to express myself:
If an ebuild (say foobar-1.0.ebuild) needs a patch affecting runtime, the
current workflow is to copy the ebuild, add the code that applies the patch
and do a revbump (to foobar-1.0-r1.ebuild). The old ebuild remains
untouched.
With the VERSIONS approach, the VERSIONS need to be adjusted to contain
the revbump version as well, and add a conditional that applies only in the
revbump version the patch and otherwise not.

The VERSIONS approach does not break the old mechanism. So if a patch
needs to be applied, the multiversion ebuild (that contains other versions
as well, say foobar.ebuild with VERSIONS="1.0 1.1 1.2") can just be copied,
renamed with the revbump number (to foobar-1.0-r1.ebuild) and completed
with the apply line. Once the old versions should be deleted the VERSIONS
variable can be adjusted (to VERSIONS="1.1 1.2").


> 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.
You are right, I have not thought about that. Maybe the approach of R0b0t1
would work.


> 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.

Gerion