There is no limitation in pms that a repo must allow/disallow usage of -r0 ebuilds; due to the implicit -r0 for when it's missing this means that dev-util/diffball/diffball-1.0.ebuild dev-util/diffball/diffball-1.0-r0.ebuild aren't uniquely identifiable- further, choice of which to use, since they sort equal, is indeterminant- meaning it'll likely vary per manager. No valid reason to allow for both forms in PMS since it allows for that conundrum; tree standard up until rbrown's commit of rubygems-1.1.0-r0 was that -r0 was left off, so the 'standard' there is established (-r0 being implicit, it must not be explicit in ebuild name).
2.4 "Uniqueness of versions". It's an issue regardless of whether -r0 is allowed, and arbitrarily banning things that are useful inside dep strings in ebuild file names just because pkgcore gets them wrong sets a bad precedent.
Suggest waiting until consensus is reached on the dev ml. While potshotting at/screwing with pkgcore is always fun, there is at least an unofficial standard in place currently which was violated by rbrown. Can be argued that this is QA (gentoo-x86 repo specific), but the bug is explicitly opened to get this pushed into pms itself. Nature of pms being that it reflects ebuild standard (which is largely defined by developer collective will), rather this bug stay open until a consensus is reached by community as a whole. You have to admit that explicit -r0 allowed on disk means the implementation is muddied dealing with it- as such I want it corrected in the spec, presuming I'm right that most folk are going to back this. Either way, http://article.gmane.org/gmane.linux.gentoo.devel/55446 is started, cc'ing QA for their commentary also as to where this belongs.
There is no issue with permitting -r0 that does not already exist for plenty of other reasons. In addition, banning -r0 would be inconsistent with existing (and widely used) practice for _alpha and the like. PMS is not the place to push through policy changes. From a technical point of view, package managers *have* to deal with -r0 and non-uniquely-identifiable versions for plenty of other reasons anyway (hence section 2.4).
Avoiding the "reopen/close" war, there are inconsistancies in manager implementation that directly trace down to this issue- PVR in portage for 1.0-r0 is 1.0. Since the -r0 is explicit, must it be part of PVR? That introduces the env oddity of 1.0-r0 and 1.0 having different PVR despite being version equal. Again, what you're missing about this bug is that there are technical reasons to push this into the spec itself- stating that it's policy sidesteps those reasons w/out addressing them. Nature of this bug *is* pushing that 'policy' into the standard to simplify the issues that exist, so kindly address the issue instead of dismissing it as 'policy'.
PVR is an entirely different issue. File a new bug for that please. As it tells you at the start of PMS, this is not the place for changing policy. If you want policy changed, do that through the proper routes, and *then* ask for PMS changes. And note that your proposed policy change will have to deal with the whole _alpha vs _alpha0 thing where people are already relying upon >=..._alpha0 matching a plain _alpha.
If nothing else then for consistency's sake we're not going to ban one way to get two equivalent versions while so many more exist and the spec already requires uniqueness within a repository.
