On Fri, Oct 20, 2006 at 05:26:00PM -0700, Brian Harring wrote: > 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 >
I suppose I see the benefit of this and as long as it accomplishes the same thing I'm looking for here, I would not be opposed. However, I think having a local version of "apache-2.0.58" resulting in "apache-2.0.58-r0.1" is kinda silly. Regardless of which method we choose, it needs to be strictly enforced that packages in the gentoo-x86 tree NOT use these revision numbers or it will ruin the whole point of them. > > > 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 > I get a little slack since the patch is simply a proof of concept ;) > > > 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). > This is a good point, but I think the types of people that would be using this feature will not have a problem making changes like this. Optionally I guess we could drop the -local# in dep calculation? It's two separate pieces of code already as you can see from the patch. > > > 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). > > I don't see any benefit to this method over the one I proposed. > > - 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... > That's correct, the regexp in current portage does require -r# to be anchored to the end. However, since the gentoo-x86 tree will not have packages with -local# someone would have to specifically try to use this new feature in an old version of portage in order to have issues. This argument here can also be applied to the -r#.# solution you mentioned, so I think the decision between -r#.# and -local# is really just a matter of aesthetics. I'm on the fence as to which is best. Would you be in support of a change that allowed for either -r#.# or -local# local revisions? > ~harring -- gentoo-dev@gentoo.org mailing list
