On Monday 31 March 2008 02:29:10 Brian Harring wrote: > Going to reiterate this one more time; the proposal is simple enough; > if it's an implicit 0 via cpv parsing, it should *not* be explicitly > specified on disk. 'diffball-1.0_alpha0.ebuild' can just as easily be > specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can > just as easily be specified as 'diffball-1.0.ebuild'. > > Reiterating the gain: consistancy on disk, consistancy in dealing with > PV/PVR. As you keep point out, PV does vary- having the results of > ebuild execution change depending on whether or not you name your > ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is > *not* a feature, it is what you would classically call a "design > misfeature". PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of > '1.0-r0' is yet another argument for punting explicit -r0 on disk- > it's a gotcha, design flaw in the format. > > It's a simple tweak, with no real loss of functionality (lots of > claims, no single hard proof thus far). As spanky has stated, there > *is* a loss of ease of use in a small subset of ebuilds- worst case, > .06% ebuilds. Personally, I don't consider that minority worth > preserving since preserving that means leaving open several gotchas in > ebuild writing, and complicates interactions (both pm and dev). > > So... there it is. Would be rather nice to have ebuild devs weight in > on this one, rather then just package manager monkeys also (they're > the ones bound most by the change after all). Laid out the advantages > to this- kindly lay out the disadvantages, where this makes things > worse if you're looking for a response.
I struggle to see the technical gain of banning -r0 while allowing _alpha0 and
002 which have the exact same technical issue. Forcing people to hard code
versions or use sucky substitutions such as ${PV/_alpha/_alpha0} or whatever
you'd use to convert cpufrequtils-2 to cpufrequtils-002 is clearly a loss of
feature.
I agree that explicit -r0 on disk isn't really useful given the current Gentoo
policy on revision bumps. But I think we established on bug #166522 [1] that
we don't want to make restrictions based on what is useful. Otherwise we
should ban _alpha_beta_pre_p too...
[1] https://bugs.gentoo.org/show_bug.cgi?id=166522
--
Bo Andresen
Gentoo KDE Dev
signature.asc
Description: This is a digitally signed message part.
