This is an unfortunate development. It's tough to fight against the tide of developers that simply don't care or honestly believe it is a good thing, but it's a fight that is worth it for better security and easier maintenance of GNU/Linux systems, which directly benefits users. Thankfully, Debian hasn't given up, nor has GuixSD that I help maintain.
I asked Tom Callaway from Red Hat about it and he said "I'm not a fan, I think its a poor decision, but I also appreciate that I might be in the minority these days." [0]
Hopefully, once enough people have been burned by the apparent convenience of bundling, we'll see the tide change. Maybe after Dockerization has run its course.
I disagree that bundling is a bad thing. Shared libraries are just as bad as a solution as the windows DLL hell. With shared libraries, you have to trust outside developers will not change function signatures or break your dependencies in some way. You have no recourse if this happens, and it does happen all too often.
It seems like an impossible mandate to ask a developer to support updating their code against new signatures and updated libraries for eternity, especially when their project is finished and feature-complete and they've moved onto newer projects. Developers bundle because we can't trust other developers not to break the rules, and are tired of the deathmarch of fixes.
The instability of libraries is enabled by the bundling culture of the ecosystem.
System libraries are extremely API and ABI stable, including libc, libz, libpng, xlib, gtk+2, glib2, etc.
npm enables bundled libraries to have their own bundled libraries, and also encourages trivially small "libraries", so the explosion of sub-dependencies is entirely unmanageable and the best you can do is let every lib bundle its own copy of every other lib and try to forget about it all.
But long-lived large linux distros, with useful applications like firefox and gimp, and a large number of common supporting libraries, show that it doesn't have to be that way. You can have just one zlib, you can have just one gtk+2, you can install bugfix and security updates for them.
API and ABI stability are good, but also no guarantee of non-breakage.
A glibc change to the memcpy implementation broke hundreds of programs a few years back. Note that it is conceivable that there were security vulnerabilities introduced by this change.
And if it comes to having a library or two with two ABIs/APIs, like gtk2 and gtk3, or libjpeg7 and libjpeg8, that's not a big deal - those two lines have different "sonames", and it's just those two versions to manage globally, rather than a per-app multitude.
>With shared libraries, you have to trust outside developers will not change function signatures or break your dependencies in some way.
With bundled libraries, the user has to trust outside developers, that didn't write those libraries, to stay on top of critical security updates to those libraries and releases new versions of their software with the relevant patches. This is completely unsustainable, both for the developer and the user.
Both solutions have flaws. This is a no-win, but it's worth understanding that neither solution is a silver bullet. I commented because the anti-bundling camp seems to think there are no benefits to bundling, and that is obviously false.
Yes, both solutions are unsustainable. Finding a better solution is where the discussion should be, not nitpicking which side is less broken.
While I'm not a fan of this development either, the position w.r.t. darktable was frankly unreasonable: the library in question is not meant to be a system library. Indeed I believe also digikam had similar problems. Having a modicum of flexibility in this cases may be positive.
It was a very contentious decision, causing a huge ruckus on the mailing list. I for one don't agree with it at all.
The only small blessing is that RPM metadata will contain:
Provides: bundled(crappy-library)
so it's possible automatically to determine what embeds that library should a security bug arise. (It doesn't make it easier to fix the N copies of that library of course).
Bundling is why chromium is (still) not in Fedora's repos[0], yet Debian has shipped it for years. I've assumed Debian was more lax on bundling or build reproducability issues - is there another reason?
This isn't really a Docker thing though, is it? It is talking about the case of a program that includes its dependencies in its own source code tree. I think docker-ized programs would still link against e.g. the system libssl rather than ship a copy of an ssl library with a program's source. Another term sometimes used is "vendoring".
A lot of Java programs ship jar files in their source tarballs, it has traditionally been a lot of work for Debian devs to pick these apart. Similarly, many "things" (programs or web services) that use javascript libraries often ship minified versions of common stuff like jquery rather than use the system version. It's quite a mess. I think a lot of it stems from the fact that traditionally these sorts of libraries (jars, javascript) have not been well packaged or even packaged at all. The program authors are making life easier for the majority by shipping all the deps together. It's not good for distros, but I can see the advantage.
I think subversion has a nice work around for this - they include a script to download the dependencies if you need them, otherwise the default is to link vs system deps.
The problem starts when you consider things like kerberos, where MIT Kerberos and Heimdal both implement the same basic kerberos api, but have mutually incompatible portions of the libraries -- there are functions that take different arguments depending on which library you're talking about, etc. So, programs that want to implement kerberos authorization need to either put in a bunch of ifdefs and the like to handle this, say that their program's just not going to work with one or the other, or bundle their own known good version. Or look at sqlite, where everyone and their brother ships their own version because there are a lot of defaults and settings which can affect behaviors that may be beneficial to an application.
Bundling is a necessity because software interactions are complex, and sometimes developers get tired of having to field support requests because packagers build programs with silly options. Including a known version of a library allows a developer to pin down the behavior a lot more, which loosens the burden on them because they don't need to worry about how Debian or Guix is going to screw up their programs.
If your distro is all about security then bundling is really bad and you shouldn't allow it if your distro is about allowing end users to use whatever software they like regardless of how it is packaged then you shouldn't care.
Just warm your users of the potential dangers installing the package may cause and move on.
I asked Tom Callaway from Red Hat about it and he said "I'm not a fan, I think its a poor decision, but I also appreciate that I might be in the minority these days." [0]
Hopefully, once enough people have been burned by the apparent convenience of bundling, we'll see the tide change. Maybe after Dockerization has run its course.
[0] https://twitter.com/spotrh/status/656677002028691456