Introduction ~~~~~~~~~~~~ What prompted this mail is the following. I was going to package Bottles for my own use. Looking at the Debian RFP list (WNPP), I found that others were interested in the same work [7], which encouraged me further. Digging deeper, however, I found that: - users will not be able to (simply) install this package on stable; - the Bottles authors have dealt with Debian-style packaging and ask not to do it [6].
Below is the context and a proposal to change Policy.
Current situation in the documentation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the Debian Policy Manual [1], section 4.13 "Embedded code copies",
the use of convenience copies is disallowed: packages must not use
embedded copies of code from other packages, except when the included
package is explicitly intended for such use. If the code is already
in the archive as a library, the package must depend on it rather
than on a copy. If the code is not in Debian, it "should be packaged
separately as a prerequisite if possible". The rationale is that
duplication makes it harder to address vulnerabilities in the code.
The Debian Developer's Reference [2] has no dedicated section on
bundling or including dependencies inside a package; it defers to
Policy on dependencies and package structure.
The Guide for Debian Maintainers [3] covers packaging practice
(debmake, dependencies in control, etc.) but does not state an
explicit prohibition or permission for including dependencies in
the package.
In short: the explicit prohibition on convenience copies comes only
from Policy [1]; for code not yet in the archive it says "if
possible". The changes proposed below clarify and extend that
possibility while requiring such packages to be clearly labelled.
The problem
~~~~~~~~~~~
In many language ecosystems (Python, JavaScript/Node, partly Go,
Rust, etc.) it is normal to pin dependency versions strictly (e.g.
using == in requirements.txt) and not to guarantee backward
compatibility even across minor library releases.
In scripting languages, binding to libraries happens at runtime — when
the application starts. So the "one library version for the whole
distribution" model fits these languages poorly.
If a Go application depending on libfoo==1.0.0 breaks when the
version of libfoo in the repository changes (e.g. from 1.0.0 to
1.0.1), maintainers may take a long time to sort it out — and
meanwhile users keep using the already-built package (it was built
with 1.0.0). For Python and
JavaScript applications this does not work: as soon as libfoo=1.0.1
appears in the repository, packages depending on it may keep working
or break — it is a matter of luck.
Facing this, many projects turned to isolating the application and
its dependencies: hence snap, Flatpak, and containers in general.
The idea of "application with its own set of dependencies" was
articulated in Alexander Larsson's "Rethinking the Linux
distribution" (2011) [4]; from it grew xdg-app (now Flatpak) and
the AppImage approach (one application — one file with all
dependencies). Many users and developers prefer such solutions over
Debian packages precisely because of the difficulty of aligning
versions in a classic repository. A telling example is Bottles [5]:
its build system is clearly designed for Flatpak (the code checks for
.flatpak-info at configure time), and building it for Debian requires
patching it. At the same time the developers ask distributions not
to build or ship native packages [6]!
Besides being a pain for developers, dependencies are also a problem
for maintainers. To add program X to Debian when it depends on
library Y, you first have to package Y. If Y pulls in Z, W, and so
on, the amount of work quickly becomes overwhelming. I would say
many programs never made it into Debian for exactly this reason.
Many RFPs (Request For Package) remain unfulfilled simply because
potential maintainers decline due to the high effort — you have to
bring a whole chain of dependencies into the archive first, often
with unclear version compatibility. And often that chain is not
needed by anyone else for any other application.
Moreover, when relaxing a dependency specified by the author, the
maintainer effectively takes on the roles of both developer and
tester of the program in a non-standard environment. Meanwhile
upstream often actively disagrees with such changes to the code,
and will not accept such patches from Debian!
Some will say: "Resolving these issues is exactly the maintainer's
job!" — and the answer is "yes and no".
Besides sorting out dependencies, the maintainer has other tasks:
checking licensing, meeting standards, integration with other
components (e.g. the desktop or the distribution's init system).
It is also worth remembering that maintainers have different
levels of experience: one might manage but is not interested,
another would like to but cannot.
In short, one could go on about this at length; I would like to put
the following proposal up for discussion:
Proposed change to Policy
~~~~~~~~~~~~~~~~~~~~~~~~~
1. Explicitly allow packaging of programs that include all required
dependencies (convenience copies, vendoring), provided that
licenses and DFSG are respected.
2. Require such packages to be clearly distinguishable from
"normal" ones that depend on separate packages from the archive.
Options (to be chosen or combined, to be decided in discussion):
- Naming: a suffix or name part, e.g. -static, -bundled,
-standalone (or another agreed marker), so that the package name
indicates that dependencies are included;
- A field in debian/control: e.g. X-Debian-Bundled-Deps: yes
(or: yes, no, partial) or similar within the existing control
structure, so that tools and users can unambiguously identify
such packages.
The goal is not to replace the current practice of "dependencies as
separate packages" but to complement it: the archive could contain
both a package foo depending on libbar and a package foo-standalone
(or with a control marker) that contains everything in one. The user
or distribution chooses what to install.
Expected effects
~~~~~~~~~~~~~~~~
- Stability: for some user-facing programs (especially GUI and
scripting), stability would improve: dependency versions are fixed
in the package and do not change when other packages in the system
are updated.
- Accessibility: a maintainer could package many programs straight
away, without first bringing all their dependencies into the
archive, which lowers the barrier and the amount of work.
- Coexistence: the repository could host both a package with
statically included dependencies and a package depending on
separate packages. The user installs one of them (with a
conflict/replacement between them if needed, so both are not
installed).
I ask that the list discuss the possibility of such changes to
Policy [1] and the choice of labelling method (package name, control
field, or both).
Conclusion (personal view)
~~~~~~~~~~~~~~~~~~~~~~~~~~
As a user I (and, I think, many others like me) want up-to-date
versions of packages such as browsers. In practice I have few
options:
- use backports — if the package has made it there;
- use sid;
- use Firefox by adding the Mozilla repository to apt;
- use Flatpak.
The sid and backports repositories are about equally likely to break
something on the desktop, so I treat them as equivalent and try to
avoid that approach. What remains in practice are Flatpak and the
Mozilla repository. I am relatively comfortable adding Mozilla's key
to my trusted set, but for a more "noname" vendor I would prefer
containerisation via Flatpak. If, however, sid had a package like
firefox-bundle that brought nothing into the system except itself,
I would use that.
Regards, @unera
References
~~~~~~~~~~
1. Debian Policy Manual, 4.13 Embedded code copies
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
2. Debian Developer's Reference
https://www.debian.org/doc/manuals/developers-reference/
3. Guide for Debian Maintainers (debmake-doc)
https://www.debian.org/doc/manuals/debmake-doc/
4. Alexander Larsson. Rethinking the Linux distribution (2011)
https://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distribution/
5. Bottles — Wine prefix manager
https://usebottles.com
6. Bottles. An open letter: please don't unofficially ship Bottles
https://usebottles.com/blog/an-open-letter/
7. RFP: bottles — graphical Wine prefix manager (Closes: #1040671)
https://bugs.debian.org/1040671
--
. ''`. Dmitry E. Oboukhov <[email protected]>
: :’ : <[email protected]>
`. `~’ work: <[email protected]>
`- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756
signature.asc
Description: PGP signature
