Le Sat, Oct 22, 2011 at 10:34:09PM -0700, Russ Allbery a écrit : > > I see those two issues as linked because of how version numbering works, > which is the key difference in using the native format. With a native > package, you only have a single version number, not a version with a > Debian revision. Therefore, each new upload of the package necessarily, > from the Debian perspective, represents a new upstream release.
I think that I am missing documentation on that topic. The Policy §3.2 mentions ‘remember that hyphen (-) cannot be used in native package versions’. That is technically untrue: dpkg can produce native packages with hyphens in the version number, and our archive can accept them, as witnessed by bzflag version 2.0.13.20080902-1. http://packages.qa.debian.org/b/bzflag/news/20080902T224705Z.html Policy §12.7 require a file called /usr/share/doc/package/changelog.Debian.gz to be present in packages that are not Debian-native. But on the other hand it does not forbid native packages to contain one. That is all the Policy tells the Developers about native packages. I do not know how our infrastructures infers if a package is native or not. I have shown above that parsing version number is not completely reliable. On the other hand, inspection of the Files field of the Debian Source control file gives a result without ambiguity. Given that hyphens are technically possible in version numbers of packages in native format, and given that our native packages are not native to our derivatives, downstream modifications can be versionned using a dash if they do not want to use a versionning scheme more similar to the one of NMUs. According to Policy §5.6.12, in the absence of a dash, the Debian revision number is 0. Accordingly, dpkg considers ‘foo’ to equal ‘foo-0’. In that sense, I humbly disagree when you write that native packages do not have a Debian revision number. I do not think that our archive is aware of the true upstream revision numbers. So using an upstream_version that increments with debian revisions as well does not seem to cause breakage. But what would prevent us to use full upstream_version-debian_revision with the 3.0 (native) format ? This seems to be the best solution. Is there a central list of native packages, or is each component of our infrastructure making the guess independantly ? I think that such information would be interesting as a footnote in the Policy, together with the addition of a paragraph in an appropriate section, where the distinction between native and non-native packages is better documented. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111023071233.gd11...@merveille.plessy.net
