Re: How can we make Debian packaging more standardised?
Hi,
On Mon, Mar 22, 2021 at 09:08:14PM +0100, Christian Kastner wrote:
> The (1) adoption of debhelper by my most packages and (2) the move to
> Salsa have been an absolute blessing. They have made contributing to
> other packages so much easier.
We have multiple standards at different abstraction levels.
If we wanted to have a single standard for everything, we'd have to keep
the full flexibility that is needed across all packages in the standard,
and that would be either massively verbose, or a very leaky abstraction
full of escape hatches.
The "massively verbose" approach is the interface described in Debian
Policy, which lists file formats and a set of core tools to interact with
them. People are unhappy with that because it's hard to use.
The "leaky abstraction full of escape hatches" is debhelper, which makes
the common cases easier, but requires "override" constructs for the
uncommon cases.
If you drop the escape hatches, you lose the ability to package a
bootloader or the kernel until you special-case them in the abstraction
frameworks and move the institutional knowledge into a collection of
special cases maintained by the authors of the framework package.
This is the same technical debate as sysvinit (massively verbose) vs
systemd (leaky abstraction full of escape hatches, moving towards a
collection of special cases maintained by a small group of people), and
likewise it has no optimal solution that offers the full flexibility of
being close to the metal at the convenience level of a high abstraction
layer, just trade-offs and preferences.
The vast majority of the software we ship works fine with a two-line
systemd unit and three debhelper control files, and that is exactly what we
should be using for these cases, but we cannot generalize that to a
requirement, and people wishing to contribute to packages not served well
by the abstraction will continue to need to look under the hood.
One aspect where we could have a debate about standards is access to
package sources, but the result should probably not introduce too many
regressions.
Right now, we have:
- unmodified original archive (sometimes signed by upstream)
- minimal download size
- mirroring and offline transport
- source code corresponding to binaries is kept, as required by the GPL
Salsa provides two others instead:
- full history
- integration with upstream version control
We currently reconcile these by exporting packages from Salsa into the
archive, dropping history and VCS integration but gaining the other three.
This is clearly suboptimal, but I haven't yet seen any proposal that
doesn't implicitly assume the availability of cheap fast ubiquitous
Internet.
One thing I could see working would be using compressed git packs inside
the archive (normal dsc, one pack containing the upstream commit and all
referenced objects, one pack containing the Debian packaging), which isn't
fundamentally different from dsc/orig.tar.gz/debian.tar.gz, but would allow
both working with unreleased upstream software and creating commits on top
that can be submitted as merge requests.
Simon
Reply to: