Aaron Rainbolt dijo [Tue, Feb 03, 2026 at 09:15:14AM -0600]:
> 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.
Well, please also consider that Debian's (and other distribution's) service
to users is not only to package their desired software in a format and
fashion easy to install, test and uninstall via a couple of "apt" commands
total, but also to show _to the various upstreams_ practices and values of
responsible software development.
In my view, if Bottles depends on patool¹ == 4.0.0, and patool adheres to a
"semantic versioning" scheme, having patool 4.0.4 (_not_ 3.9.9, which might
be a completely different beast!) breach expectations and break API
compatibility not only with 4.x.x, but with 4.0.x... Bottles' upstream
should understand that the bad behavior les _with patool_. And they are
_not_ doing their users _any service_ by depending on specific versions
that might introduce vulnerabilities that might never be fixed (or that
could be fixed in 4.0.6, which... bugger != 4.0.0, is discarded!)
¹ I'm sorry, I'm not familiar with Bottles or patool, and might be
mischaracterizing them; I'm just using the original poster's choice of
software
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.
For me, the ability to fix a buggy library is a core value (both in the
sense of "that's what we do, those are our values' and in the sense of
value provided to users) that a distributions provides to its users. I know
I am not alone with this view. I suggest you also consider Bastien
Roucaries' paper presented in DebConf25:
Static linking: pitfalls, harms and challenges
https://hal.science/DEBCONF/hal-05334923v1
Greetings,
– Gunnar.
