On Fri, Oct 20, 2006 at 11:05:22PM +0000, [EMAIL PROTECTED] 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
pgpshCSYqk7sx.pgp
Description: PGP signature
