On Tue, Aug 18 2009, Don Armstrong wrote: > On Tue, 18 Aug 2009, Manoj Srivastava wrote: >> Given these, I read this as letting the tools rely on >> the following invariants, even though these are not explicitly spelled >> out in so many words in policy: >> >> 1) If there is a - in the version number, then the package is >> non-native >> a) the upstream version is the part of the string until the last >> '-' in the version number >> b) there is a .orig.tar.gz and >> c) diff.gz referenced in the .dsc >> >> 2) If there is no '-' in the version number, then the package is a >> debian native package >> a) there is no debian revision, all the version number is the >> upstream version number >> b) there is a tar.gz and no diff.gz in the .dsc file > > (1) is not necessarily true in the case of NMUs of native packages.[1] > The only way to tell if a package is native or not is to inspect the > .dsc. [So long as the as-yet-to-be-proposed wording is clear on this, > it should be a big deal.]
I understand today that perhaps NMU's of native packages do not follow 1. However, consider this: >> 1) dch --nmu adds +nmu1 for native packages >> 2) +nmuX is already supported by devscripts and lintian. >> 3) the developers reference also advocates adding +<codename>\d+. It >> also advocates using exactly the same tar.gz file as already in the >> archive. >> 4) this is how debhelper, cdbs, and my packaging scripts handle it. >> >> Please also look at the discussion below, which led to >> developers reference changing its recommendation. >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 That link states that debhelper, cdbs, and (ahem) my scripts all use the same convention for distinguishing native packages from non native ones, namely, the presence of a hyphen in the version number. I am suggesting, in this case, we *make* policy to explicitly adopt the design that the dev-ref, devscripts, lintian, etc all currently espouse; with perhaps the proviso that this be a should or perhaps recommended bahaviour for a while. I consider having to look into a .dsc file to see whether a package is a native NMU or a non-native package to be a flaw large enough to warrant making policy here, especially since debhelper and cdbs and devscripts all follow this. As far as policy is concerned, there is a strong indication that if there is a - in the version, there is an upstream package, and there is a debian revision, and there are also indications that a non-native package needs to have orig.tar.gz/diff.gz. Making a package seem like it is native and non native based on whether the last upload was a NMU is bad, and it contradicts both policy on version number format and the def ref recommendations. > That said, the rest looks reasonable, but it would probably be useful > to make sure that we're actually representing current practice. Given that devscripts, lintian, and the dev-ref all advocate or implement +nmu\d+, and that debhelper and cdbs look at the hyphen for determining native vs non-native, I have tried to do so. I think the proposed practice is strictly better than not specifying any conventions, and where possible, Ihave tried to stick to best practices as documented in the dev-ref to base policy on. Having said that, there are a lot of packages that seem to still use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this policy change as a 'recommends', and letting lintian warn about the version number. __> egrep '^Version: ' /var/lib/dpkg/available | wc -l 26797 __> egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/ && print' | wc -l 2127 Of course, the majority of these packages are not native packages, but it is hard to tell which are which. manoj -- "Cynicism is an unpleasant way of saying the truth." Lillian Hellman 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-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org