Yesterday, a package (redis-server) for Debian Stretch in non-backports repository was updated, and now relies on a package not present for Stretch (libjemalloc2).
The problem isn't so much that Debian packages or the ecosystem "breaks" as such, but that you run in to bugs (sometimes already fixed ones), and that you're then basically stuck with that unless you, the maintainer, or someone else decides to backport the fix, and they frequently don't get backported especially not for "minor" bugs.
This isn't the only time Debian has introduced a serious security vulnerability by changing things in packages. The most notable prior example that comes to mind is CVE-2008-0166.
Did you run your debian with backports? That solved most problems for me, and restricted the changes to the packages themselves, without pulling in to many new dependencies.
Ubuntu LTS can have outdated packages, too, and no backports there, last time I've looked.
Oh, my bad - it was the default config in Debian package that got changed. I assumed it originated from upstream, but I was wrong and it's actually patched by Debian maintainer:
It's a new regression, only found in Debian stretch (not yet released) and caused by an incompatible change in another package. As far as Debian is concerned, this is just the process working as intended.
This is just another one of those reasons I just can't use Debian responsibly.
Backport hacks always come back to bite you in the end when your distro is running unsupported software, and it feels like I see something at least annually about Debian's "ensure everything is old so all bugs are predictable" ends up just causing pain.
Not even the maintainers really understand what they are doing :
https://github.com/g0tmi1k/debian-ssh
> There was an #ifndef PURIFY there for a reason. It's because the openssl authors knew that line would cause trouble in a memory debuger like Purify or Valgrind.
Where a debian maintainer screwed the RNG of OpenSSL to make valgrind happy. This made any key generated on a debian or ubuntu system from 2006 to 2008 very easily breakable.
Downstream should never touch packages beyond backporting fixes made by upstream.
Here's another example of upstream vs downstream conflict in debian :
This is why I heavily support the desire for a new packaging system targeted at developers: snaps, flatpak. The downside of having multiple copies of the same libraries pale in comparison to giving back power to upstream. Distro maintainers are routinely modifying codebases they don't understand. Allow us to have a standard installation process that can install packages.. made by the developers themselves, upstream. Just like all other operating systems do.
And Debian, unlike RHEL/CentOS, packages a lot more than they can even reasonably maintain. The vast majority of packages in a Debian stable are insecure, the security team simply cannot handle the large amount of software outside of the truly core stuff (kernel, web servers) :
If you aren't supposed to use the packaged wordpress, phpmyadmin or node, why is debian distributing those packages? Debian by distributing these things in their repo encourages the naive first time linux user to install them through their facilities.
I guess Ububtu is waiting for Debian to update to BIND 9.11, but Stretch is still on 9.10. It is a pity the next Debian release is not on 9.11 since that will be an ESV branch. https://www.isc.org/downloads/software-support-policy/
https://packages.debian.org/stretch/redis-server
So much about not breaking things.
reply