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

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

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