Sam Hartman <hartm...@debian.org> writes: > Specifically, I'd like to ask the TC to come up with policy on native > packages and debian revisions using its power under 6.1.1.
As a Policy Editor, I support this request. I've been involved in a lot of these discussions over the years, and the tentative conclusion that I've come to is that we have unfortunately mixed several different concepts in how we talk about source packages. This has not *technically* reduced the flexibility of the packaging format because there are various workarounds, but it's *conceptually* reduced the flexibility in a way that makes those workarounds look conceptually incorrect. As a result, we have constant repetitions of similar arguments stemming from well-meaning attempts to clean up the apparent inconsistencies (including some I have started). There are really two separate concepts in play here: 1. Different version numbering conventions for native and non-native packages. For non-native packages, we want to preserve the upstream version number as much as possible so that our users can correlate our packages to upstream releases. We therefore have the Debian revision component of the version number. But we don't want to use that component for native packages, since there is no corresponding upstream version. And I do believe that we need to keep the concept of native packages. There are configuration-only packages, metapackages, and other cases where even with an extremely aggressive idea of what should entail a separate upstream release, a separate upstream makes no sense. And I can also confirm that outside of Debian native packages are heavily used by Debian users to package local things. 2. Source package formats. Here, people want different things based on different workflows. We may have opinions about which workflows are better and which are worse, but by and large Debian tries to provide room for innovation on workflows, and there are some important workflows outside of the archive (such as automated builds from CI as Sam has mentioned) where simplicity is far more important than careful tracking of distinctions between upstream and Debian changes. There is a clearly-expressed desire to support a package format with as simple of a representation as possible for some of those workflows, either because the complexity is being handled at another level or because the complexity is make-work for the desired goal that isn't worth doing (true for a lot of out-of-archive use cases). The current native format of a single tarball that you unpack and can then build as a Debian package with no further work is exactly what many of those workflows want. We have conflated 1 and 2, but I don't think they are as closely related as the project has conceptually presented them. There is a tie in that *if* there is a separate upstream release, then someone may want a package format that allows keeping the Debian pieces and the upstream pieces clearly separate. But in practice there are reasons to want to use the single-tarball source format for a non-native package. (I admit I am unable to think of a plausible reason to use the multiple tarball or tarball with patch format for a native package, but that may be a failure of my imagination. I can think of some space-conserving reasons to want to use that packaging format if the archive would reuse the tarballs, but the archive software won't when using native versioning, and changing that would be extremely difficult and probably not worth the effort.) What I would propose is to separate these concepts cleanly so that we can talk about them in a clearer way. We should define native and non-native packages in terms of version numbers, and allow both native and non-native packages to use single-tarball source package formats. We may want to steer people away from using the single-tarball source package format for the *normal* case of packaging upstream software, but I think it's well within the sorts of trade-off decisions that packagers already make and there are cases where a single tarball source format makes sense. The name of the 3.0 (native) source package format is unfortunate in this context since it strongly implies that only native packages will use that source format. The most formally correct thing to do would probably be to introduce a new 3.0 (single-tarball) source format and use 1.0 until then, but of course introducing a new source package format is not a fast process. A more expedient thing to do may be to allow use of 3.0 (native) with non-native packages, since it's identical to 3.0 (single-tarball) except for the name, but it does leave a long-term confusing naming scheme in place. Guillem may well have other and better suggestions from the dpkg perspective; I haven't thought all that much about a transition plan. Note that this only addresses the first part of Ian's request. The second part, the 1.0 with patches format, I believe stems from different problems with the 3.0 (quilt) format that are unrelated to the native vs. non-native package distinction. I have no useful opinions to add on that topic. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>