Re: [gentoo-dev] RFC: Portage local package revisions

[Brian Harring]

On Fri, Oct 20, 2006 at 11:05:22PM +0000, malverian@g.o wrote:
> Hello all,
>
> In designing an enterprise infrastructure around Gentoo at my place of
> employment, I have discovered a feature that would improve Gentoo's
> usefulness greatly in this field.
>
> I'm writing to ask for your opinion on a change to sys-apps/portage that
> would allow users to maintain local revisions of ebuilds, such as
> "net-www/apache-2.0.58-r2-local1". This would require a modification to
> the ebuild version specifications and a patch to two portage source
> files which you can review here:

Use -rX.Y instead; existing portage will choke on it the same as it'll 
choke on -local, upshot of -rX.Y is that it's less chars, bit more 
clear in the intention of trying to sneak an additional version 
component betwee -rN and -rN+1


> http://dev.gentoo.org/~malverian/portage_local_version.patch
>
> (Please don't complain about the code quality, I cleaned up areas where
> it was desparately needed such as the string.atof() areas, but for the
> sake of code coherence, I tried to use the same methodology used elsewhere
> in the code as much as possible, such as unqualified except statements :P)

Bah.  If you know that catch-all except's are bad, that means you 
can't use that excuse for having it in your new code :P


> 2) You are using binary packages and need to simulate a version bump to
>    force re-installation of a binary package with modified USE flags.
>
> 3) You are using binary packages and need to simulate a version bump to
>    force re-installation of binary packages that were rebuilt during
>    revdep-rebuild

Failing here is that it's not a 'simulated' verbump, it *is* a verbump 
for any deps that are locked via =; =dev-util/diffball-0.7.1 will not 
pick up =dev-util/diffball-0.7.1-local1 since =dev-util/diffball-0.7.1 
is implicitly =dev-util/diffball-0.7.1-local0 .

Folks can live with that issue, but should be clear that its there 
(same for revbumps of course, just picking at the wording).


> In all of the above cases, one could simply bump the package up one
> revision by creating an ebuild in an overlay for apache-2.0.58-r3.
> However, using this solution will result in apache not being upgraded
> when apache-2.0.58-r3 is actually committed to the portage tree unless
> you perpetuate this bad habit ad nauseum.

This particular issue (force usage of an ebuild from PORTDIR if the 
installed exact version is from an overlay) can be addressed without 
changing version rules, although admittedly it's a single revbump, no 
way to do multiple bumps (again, wording is all).


> - The new (completely backward compatible) version priority order would be:
>
>     apache-2.0.58
>     apache-2.0.58-r1
>     apache-2.0.58-r2
>     apache-2.0.58-r2-local1
>     apache-2.0.58-r2-local2
>     apache-2.0.58-r3
>     apache-2.0.59

portage_version.ver_regexp specifically anchors -r\d+ to the end of 
the string, as such this is *not* backwards compatible, 2.1 
would choke if it saw these versions in the vdb or in an 
overlay...

~harring