On Thu, May 17, 2018 at 11:44 AM Gerion Entrup <gerion.ent...@flump.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
