On Thu, Aug 20 2009, Steffen Joeris wrote:
> I haven't followed all the discussion around this, so please excuse my
> ignorance, but could someone try and explain to me in simple terms what we
> are
> trying to fix with all this policy stuff around versioning?
> I don't see why we have to replace our usual convention of:
> - Add a ".X" for normal NMUs (including security NMUs to
> unstable/experimental)
> - Add "+$codenameX " to uploads for oldstable/stable/testing (for security
> and
> non-security, regardless of whether NMU or MU)
>
> The only problem I could think of is when we start having a codename that
> starts with "a", since the binNMU convention is to add "+bX".
> But I'd worry about that problem, when it arises (is there a toy story
> character starting with a? :) ).
Well, it started with there being some confusion on what
determining what was a native package, based on version numbers: and it
turns out that while policy is clear about the distinction of an
upstream version part and a Debian specific revision part (and,
personally, it ought to follow that for a native package there is no
Debian specific version, since it is all Debian specific), because of a
practice some packages had of appending -0.1 for NMU's of native
packages, making it impossible to tell if it was the NMU of a
non-native package, or the NMU of a native package, without looking
into the .dsc. This is unnecessarily hard, so some policy language
carving out a name space for NMU's would be nice.
Then there as the issue of NMU vs codename specific NMU's (like
security or backports), +codename\d might lexically sort before
+conename++\d, if codename ++ sorts earlier. So coming up with +deb and
+debt seems to stave off future issues with versions not sorting
correctly.
This also makes new NMU's sort later than older codename
specific uploads.
There is a preponderance of best practices already in play, and
putting them into policy just gives them greater weight, and makes it
possible for tools to depend on these naming rules.
The one issue I see is that +nmu\d is not common for non-native
NMU's, though I think a consistent scheme is to be preferred, for ease
of implementation in tools and grep-dctrl searches.
I am tempted to still recommend +nmu\d as the version suffix for
any NMU, end have lintian gently warn about it. My opinion is that it
is regrettable if we went the route of the popular choice rather than
the slightly better technical one, even if it is not the vogue; since I
think that having a dependable, and simple, rule would be useful
enough. Your mileage may vary.
I also understand that there are a myriad of choices we may make
about naming, most of which are technically viable, but I think this is
precisely the role for policy, to make a decision between several
equally viable technical choices, if it helps integration and tools.
manoj
--
An ignorant man ages like an ox. His flesh may increase, but not his
understanding. 152
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
