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

Reply via email to