Quoting Dmitry E. Oboukhov (2026-02-03 15:12:43) > > > 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. > > > > Quick question (not hostile, just to clear it up): you do realize that > > this means that the package's copyright file would need to document > > all the licenses of all the bundled packages, right? At the very least > > to provide enough information for users and downstream distributions. > > Yes, you're right. I wasn’t quoting Policy verbatim. On one hand, > you’re correct: Debian does have packages with static linking / > embedded copies, and I’ve also added such packages in the past. > > On the other hand: if I package the aforementioned Bottles and a > reviewer rejects it with something like “the following packages > already exist in Debian, please rework the package” and lists e.g. > python3-gi, python3-gi-cairo, python3-cairo, python3-yaml, > python3-pycurl, python3-requests, python3-markdown, python3-chardet, > python3-idna, python3-urllib3, python3-certifi, python3-pefile, > python3-yara, python3-charset-normalizer, python3-orjson, > python3-pathvalidate, python3-icoextract, patool, fvs > > — who is “right” in that situation? > > The wording of Policy leaves that unclear. > > If Policy explicitly allowed (or disallowed) this way of packaging > (with the labelling we’re discussing), there would be nothing to > argue about in cases like that. > > PS: The Bottles authors asked distros not to package them > precisely because the result is not guaranteed to work. If they > say "depends on patool 4.0.0" and Debian ships 4.0.4 (or 3.9.9), > they can reasonably feel the distribution is shipping something > that misrepresents their project — and in a way they're right. > > That’s exactly the kind of situation the proposal is meant to > address: a bundled/standalone package would ship the version the > upstream actually tested, instead of whatever the distro has.
If "not exactly as shipped, including dependencies" is considered misrepresentation, then it sounds to me that Debian is reduced to a service for compiling and hosting code. I mean, if a new *revision* of a dependency - i.e. something *expected* to not affect the ABI of consuming code - is causing eyebrows or worse from upstream, then how about bugfixes and patches that Debian does *without* changing version numbers, again because the changes are expected to not affect the ABI? Or what if Debian decides to "fix" a deep dependency to not spy on its users - that's arguably not a security bug but still somethig that is altering from a do-not-touch-anything-even-in-dependencies stance? What if... for each and every patch that Debian decides to apply to the packages which this appreach intends to bypass? Why package something in Debian, if you do not expect Debian to mean something - some level of governance and tending to the pieces? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
