Re: git-buildpackage and tarballs
Charles Plessy <plessy@debian.org> writes:
> I think that I am missing documentation on that topic.
Yes, I seem to recall there's an open Policy bug for the fact that native
and non-native packages aren't particularly well-documented.
> 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
Regardless of the presence of past bugs, native packages by definition do
not contain a Debian revision. Lintian will certainly complain loudly
about violations of that rule. I think DAK should also reject them as
they're a fairly clearcut Policy violation and cause various confusions
for other tools that, following Policy, decide whether a package is native
or non-native based on the version number (which is the only way that such
a determination can be made if all one has is a binary package). I don't
know if it actually does.
> That is all the Policy tells the Developers about native packages.
Native packages are also discussed in Policy §5.6.12 (see below).
> I do not know how our infrastructures infers if a package is native or
> not.
For all version 1.0 packages, it's determined by the version number, and
that in turn determines what files are generated for the source package.
(If there is a separate Debian diff, for instance.) Inspecting the *.dsc
file is obviously not sufficient if one is trying to generate that file.
For version 3.0 packages, dpkg now has a way of distinguishing without
looking at the version number, which creates the possibility in dpkg of
creating a native package with a non-native version. However, Policy does
not permit that, so such a package shouldn't be uploaded to the archive.
One could, I suppose, argue for a Policy change, but it's really not a
sensible thing to do; a package with a Debian-specific revision number is,
by definition, non-native, since a native package would not need a
Debian-specific version separate from an upstream version (since there is
no separate upstream).
I realize that you're interested in the technical properties of a 3.0
(native) package in particular, and not at all in the "nativeness," but
for good or for ill those two things are completely merged in the current
package format, and there is no way to get a non-native package using the
3.0 (native) layout (which is what I think you want). It might be an
interesting enhancement to dpkg to add it, although I'm not sure I really
agree with the use case since we lose various other things, such as the
Debian-specific diff or tarball (frequently used by upstream to understand
what we've changed).
My understanding from things posted by the dpkg developers is that the
addition of a way of explicitly declaring the native package format was
not intended as a way to allow native packages to have non-native
versions, but rather as an additional error checking mechanism and a way
of making explicit a decision process that was previously implicit.
> According to Policy §5.6.12, in the absence of a dash, the Debian
> revision number is 0.
No, that's not what it says. It says that the absence of a Debian
revision is *equivalent* to a revision number of 0, which isn't the same
thing. It's part of the sorting rules and is phrased that way to simplify
the description of the sorting rules by eliminating the need for a special
description of what to do with an empty Debian revision later on.
> 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.
Policy directly contradicts you in the same section that you're quoting,
two paragraphs earlier:
[The Debian revision] is optional; if it isn't present then the
upstream_version may not contain a hyphen. This format represents the
case where a piece of software was written specifically to be a Debian
package, where the Debian package source must always be identical to
the pristine source and therefore no revision indication is required.
This, albeit oddly placed, is the formal definition of a native package in
the current Policy text. (I agree that it leaves a bit to be desired.)
> 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.
But it's not, since that version numbering makes no sense for a native
package, where there is by definition no upstream. You aren't talking
about a native package in the Debian sense; this whole thread has been
about packaging software with an independent upstream existence. In other
words, a non-native package. You like some properties of the 3.0 (native)
package format for packaging non-native software.
Put another way, I think what you're proposing (using a native package
format for non-native packages) is an ugly hack, and one that loses
information. We shouldn't be using hacks in something as fundamental as
our source package format; we should be striving to use correct solutions
to technical problems. If we want to use a source package format similar
to 3.0 (native) for non-native packages, we should define such a format,
not abuse the native package format for that purpose and lose the
meaningful distinction between a native and a non-native package.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: