Quoting Aaron Rainbolt (2026-02-03 16:15:14) > On Tue, Feb 3, 2026 at 9:00 AM Jonas Smedegaard <[email protected]> wrote: > > > > 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? > > It's not causing "eyebrows or worse from upstream", it's causing > literal breakage which is causing upstream issues. Software *should* > make sure to not affect ABI/API in minor releases, but a lot of it > *doesn't* in practice, and this is one of the pain points where it > shows. > > > 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? > > The stance I do not believe is "don't touch anything even in > dependencies", it's "don't do things with dependencies that cause the > application to malfunction". Debian is exceedingly careful to make > sure that its patches don't break things. I don't think Debian patches > are an issue here.
If I understand you correctly, then the problem you are trying to address ultimately is, that some projects may need shiny new version 4.0.4 of some library, while others crash with that version and instead need old and boring version 4.0.0 of that same library. I.e. that your proposal to loosen Policy is a way to reach that other ultimate goal. I don't recognize that other ultimate goal as being inachievable currently in Debian. I do recognize it being a lot of work to maintain in debian a project which has a lot of dependencies and/or is unusually picky about its dependencies. And I can certainly agree that it would be less work to not need to *maintain* that. Or to use a friendlier phrasing, to maintain *differently* than how it is currently done in Debian. But I fail to recognize that as being about Policy constraints. Instead, I am concerned that this kind of change to Policy might (accidentally, of course - we are not considering deliberate ill intentions here) weaken the level of maintenance of Debian packages. - 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
