Bug#1007717: Native source package format with non-native version
Sam Hartman <hartmans@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: