Re: git-buildpackage and tarballs
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
Reply to: