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

[Rich Freeman]

On Thu, May 17, 2018 at 11:44 AM Gerion Entrup <gerion.entrup@×××××.de>
wrote:

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


Sure, but now you're back to single-version ebuilds except that you have to
stick the version inside the ebuild instead of just in the filename.

When would you actually get any of the code-sharing benefits of
multi-version ebuilds?  If you fork them anytime there is a revbump then to
actually share code you'd need the ebuilds for both versions to be issued
at the same time and have near-identical code.  How often does that happen?

I think in practice this just makes things more complicated.

And this problem isn't just limited to keywording.  If you don't want to
make retroactive changes to released packages then you need to make all
code changes conditional on version, which makes the ebuild a rat's nest of
conditionals.

I could really only see something like this working if the entire Gentoo
repo were release-based, because then you'd tag a release, and then you can
modify all the code you want in-place because it wouldn't affect anything
in production.  Then you do a round of QA and issue a new release.  Since
Gentoo's QA operates at the package-version level you really need to make
your changes in new package-versions (including ebuild revision numbers).

-- 
Rich