
Fedora opens up to bundling - perlgeek
https://lwn.net/SubscriberLink/660429/b749a0be5843e95a/
======
davexunit
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.

[0]
[https://twitter.com/spotrh/status/656677002028691456](https://twitter.com/spotrh/status/656677002028691456)

~~~
Afforess
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.

~~~
ploxiln
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.

~~~
legulere
It's funny how you listed e.g. libpng but not libjpeg which breaks the ABI
very often.

~~~
ploxiln
libjpeg is silly, but that's why everyone uses libjpeg-turbo now, which
maintains API/ABI compatibility with libjpeg v8

[http://www.libjpeg-turbo.org/About/Jpeg-9](http://www.libjpeg-
turbo.org/About/Jpeg-9)

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.

------
weland
Folks, please read the article. This has nothing to do with Docker.

It's referring to bundling _as part of RPMs_ , i.e. on having application
packages bundle some or all of its dependencies along with the application.
This is generally frowned upon, and with good reason, but it's being practiced
with an increasing frequency.

The Fedora devs have had a lot of problems with this over the years. More
recently, libraries like rawspeed have sprouted everywhere -- they are meant
to be used _only_ as bundled libraries.

So they either had to change the rule and allow bundling, or to find
themselves unable to distribute applications that are otherwise useful to
developers, I guess. They "opened up to bundling" in that they introduced a
new provision which allows bundling in cases where there's no alternative, but
the RPM has to be marked as including bundled dependencies.

Don't get me wrong, I'm all for bashing Red Hat's perpetual beta crap distro,
but this time they got it right. Really. It's a sensible decision, not some
wavefront of Linux innovation bullshit.

------
vezzy-fnord
_Policies that are out of line with reality are bad policy: the war on drugs
does not fix drug abuse, vagrancy laws do not fix poverty, and the war on
bundling merely ensures that bundled software goes unreported._

The metaphor doesn't pan out. The third is canonizing a technical error.

~~~
kedean
That's an opinion. There's a whole debate on bundling vs sharing, and neither
opinion is canonically correct. That said, it is only a 'technical error' in
your view that shared libraries are the only way.

~~~
vezzy-fnord
Bundling involves shared libraries. I'm not sure where you came up with this
distinction.

~~~
kedean
In this entire post, bundling refers to software that includes a specific
version of each library in its own binary, while shared refers to software
that uses the system version and requires dependencies to be installed out of
band (possibly by the package manager). They are competing ideologies.

~~~
vezzy-fnord
Both approaches involve shared libraries, which are simply dynamically linked
objects. The article outlines a problem of _distribution_ , not linking
strategies. You're using shared libraries in both contexts.

This is a misuse of well-established terminology. To say this is an
ideological issue is a balance fallacy, as the package management approach has
long been shown superior (by the likes of e.g. Nix and Guix).

~~~
kedean
Both sides have their arguments, as outlined by
[https://news.ycombinator.com/item?id=10425913](https://news.ycombinator.com/item?id=10425913),
so it's really not a black and white 'technical error' issue.

------
Skunkleton
I have worked on several large applications where libraries were customized
and bundled in. We would have been better off in the long term implementing
the small delta we needed from the library in our application. In every case I
saw, it was just an example of lazy engineering that led us to bundling.

------
mgrennan
Why Docker, why not RPMs they are not that hard to build. They have years
design an work behind them. I hate bloat. 20 years ago I could get the same
work done today in 1000th the memory and disk space.

------
matt_morgan
I've used (servers and laptops and desktops) Fedora and Ubuntu for many years.
Since the advent of package management, Fedora has been significantly more
"just works" when it comes to anything slightly professional or complicated
(of course Ubuntu has had the edge on personal multimedia), and I'll bet this
practice of discouraging bundling is a huge part of that. On the other hand,
Fedora usage is falling, proportionally, right? I'm not sure, but it seems
like it. Anyway: tough call.

~~~
dijit
Fedora usage is falling probably because many previous fedora users are a bit
jaded with RedHat, the way systemd has been shimmed into everything- there's
no benefit to using fedora over Arch linux anymore, you get more control and
you don't have to fight the system to get anything technical done.

Or, they went to the UNICEs, which is what I did.

(this is anecdotal, I only know a dozen or so fedora users and they all jumped
ship recently because they felt the offering is sub-par now)

~~~
andor
_Fedora usage is falling probably because many previous fedora users are a bit
jaded with RedHat, the way systemd has been shimmed into everything_

Or you could appreciate that Red Hat funds so many great projects and cares
about the future of Linux.

 _there 's no benefit to using fedora over Arch linux anymore_

Fedora Workstation is easy to install and has a usable default desktop. No
need to tinker with the OS, you can be productive very quickly. Last time I
checked, Arch didn't even have an installer.

~~~
dijit
what use is an installer when your OS never breaks?

the only reason I'm so familiar with anaconda is that my system would break in
random weird and inexplicable ways on occasion.

------
anonbanker
I left all things RPM in 2003. All developments since have not proven that
decision to be in error.

With the promotion of NetworkManager, PulseAudio, systemd, and now these
bundling practices, we shouldn't even be calling this a GNU distribution
anymore. it's Redhat's Job-security-by-obscurity stack that happens to be
running on a linux kernel. And all distributions that adhere to this new
standard base (arch, debian, etc) should be considered to that same
definition.

~~~
qznc
After your restriction there are not many distros left. Slackware user?

~~~
anonbanker
Gentoo user, but Slackware is definitely an option still. Linux Mint Debian
Edition still doesn't use systemd. nor does Morpheus Linux.

But yes, there aren't very many GNU/Linux distros left.

------
SEJeff
I think this makes it exceptionally hard for a distro with languages like
golang, where vendoring libraries is _the_ norm vs the exception.

There were some serious issues with this on the golang-nuts fedora ML some
time ago where lsm5 was lamenting about the issues Fedora faces when upstream
simply won't remove vendored libs.

~~~
davexunit
Go in many ways is a bold step backwards in software engineering.

~~~
LunaSea
Why ?

------
digi_owl
Seems to fix the wrong problem to me.

The major issue, as best i can tell, is that most package managers can't
handle having multiple minor versions of the same lib installed side by side.
This because they sort on name-version basis.

Heck, even with major versions the separation is usually a hack by putting the
major version number into the name part of the package id (name1-version,
name2-version, etc).

Thus you get conflicts when you want to install name-version and name-
version+1 at the same time.

This is not a Linux problem though, as on the OS level the libs are separated
using the soname system.

[https://en.wikipedia.org/wiki/Soname](https://en.wikipedia.org/wiki/Soname)

