On Tue, Feb 3, 2026, at 4:55 PM, Simon Richter wrote: > Hi, [..] > The most problematic ecosystems, in my opinion, are cargo, npm and > golang, but we mostly lack insight here -- we have no statistics on how > much duplication exists inside the archive, how many of these could be > avoided by folding them together, and how many binary packages we could > save in the other direction by vendoring libraries that only have a > single user and are statically linked anyway. That's why my proposal > goes towards making these transparent and trackable first.
for Rust, from the top of my head: - firefox(-*) - chromium - thunderbird(-*) for all of these the argument was that upstream vets their dependencies at least as well as Debian does, and both require backporting-to-stable exceptions for security support that are not compatible with the number of dependencies they'd have without vendoring. - librsvg (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017892) - rustc+cargo (circular bootstrapping loop with 1000 entries) I am sure there are others that I forgot or am not aware of, but AFAIK these are exceptions and not the norm. We do have around 3k rust source packages for a reason ;) improving tracking for the existing ones while they are still vendored would be nice. > [..] > IMO, we should also include API/ABI stability as a factor into whether > we actually want to release a package as part of a stable distribution. for sure > We have several upstreams who are bluntly telling us that they are > unwilling to support users running Debian stable, so at this point the > decision to release such a package as part of a stable release is a > commitment by the Debian maintainer to provide this user support. yes > For a package with a lot of version-pinned dependencies, that commitment > can be massive, and should not be taken on lightly; on the other hand, > for a lot of these packages vendoring is the only approach that makes > this feasible in the first place. at least in the Rust world, pinning exact versions is very rare (outside of sets of crates part of a single upstream project that are released in lockstep, or pinning to avoid specific breakage in more recent versions). the dependency information is split into Cargo.toml specifying what *should* work, and Cargo.lock specifying what was used upstream. the latter can be used to match upstream when building with cargo, but is not used when packaging, because the versions contained there never match what is in Debian's archive. Fabian
