Charles Plessy <ple...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87ipngru03....@windlord.stanford.edu
