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