Le mardi 3 février 2026, 12:29:18 heure normale d’Europe centrale Dmitry E. Oboukhov a écrit : > 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.
No we patch for debian and we try to keep only a version on the whole tree. Here it is a inexact, and js package have good test suite that allow this. > > 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. You lack security implication, and it is huge one Please see my paper on scientific track of debconf brest about clone attack They exists middle way between that we expect, like leaf linking and so on please read carefully my paper. > > 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. They could bundle like javascript using multiple tar, this is already implemented We do this for js, may be generalize Moreover js package anotate automatically > > 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 > >
signature.asc
Description: This is a digitally signed message part.
