Have you seen policy bug #907051? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907051
Your proposal seems even more liberal in basically willing to accept upstream vendoring as-is, despite multiple versions etc. Personally I think there's an easy way to achieve your (2) that they are easily distinguishable, just host a repo and add its details to extrepo-data. On 3 February 2026 11:29:18 GMT, "Dmitry E. Oboukhov" <[email protected]> wrote: >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
