Comment by xg15 | Hacker News Reader

Comment by xg15 | Hacker News Reader

> One of the basic concepts shared by most Linux systems is centralization of dependencies. Libraries should be declared as dependencies, and the packages depended on should be installed in a common location for use of the linker. This can create a challenge: different pieces of software might depend on different versions of a library, which may not be compatible. This is the central challenge of maintaining a Linux distribution, in the classical sense: providing repositories of software versions that will all work correctly together.

Maybe someone with more knowledge of Linux history can explain this for me, because I never understood it: Why is it so important that there must always only be one single version of a library installed on the entire system? What keeps a distribution from identifying a library by its name and version and allowing application A to use v1.1 and application B to use v1.2 at the same time?

Instead the solution of distros seems to be to enforce a single version and then to bend the entire world around this restriction - which then leads to unhappy developers that try to sidestep distro package management altogether and undermine the (very reasonable) "all software in a distro is known to work together" invariant.

So, why?

If there's a chain of dependencies (libraries depending on other libraries), a single process might end up with different versions of the same library in it's memory. That's not going to work, since the interface/API of the library is typically not versioned.

True, but shouldn't this issue already show up when a developer builds/tests the application on their own machine?

For security (and general bug fixing). If a security issue is found you want to only fix it in one place. The container alternative is searching down how all the containers were built, which might be very varied and some not even reproducible, and fixing them all.

Indeed, containers suck for this: Not just do you have to look into each container separately, there is also no requirement all containers use the same structure at all, as you said.

Yet this is exactly what happens in practice if the one-version-for-all paradigm is impractical for developers.

So it would be in the interest of distros to give some way in that regard: Keep the centralised dependency dogma in place, but allow multiple independent versions and configurations be stored.

Then bug fixing might be slightly harder than with a single version, because you might have to fix 3 versions instead of one, but still much easier than monkey-patching half a dozen containers.

(It would still be good to "nudge" developers towards a canonical version, i.e. by sending them reminders when the software uses a lower version or a different configuration - or if you want even a warning that everything below a certain minimum version will be rejected)

Distros do this already, at least some do. It depends on the distro exactly how it is done, but Debian certainly allows multiple versions of libraries to be packaged (with variant names: https://packages.debian.org/buster/libreadline7 vs https://packages.debian.org/bullseye/libreadline8), and in Fedora, compat-* packages are used to store previous versions of libraries (eg: https://koji.fedoraproject.org/koji/packageinfo?packageID=23...)

There's usually some soft or hard insistence that the package that depends on the old version of the dependency should have a plan to update to the new version. Definitely in Fedora we don't "like" compat libraries, although we tolerate them.

An interesting fact is the original RPM specification was designed to allow parallel installation of different versions of the same-named package. However at a distro level it turned out to be quite difficult to use this, because you have to be really careful about file conflicts. So now it is disallowed, except for the kernel package.

Why not to become a maintainer and solve this problem for us? It looks like you have the vision.

Fedora had support for modularity: https://docs.fedoraproject.org/en-US/modularity/ . Join the Fedora project, please.

What's with the passive-agressiveness?

The idea is as basic as you can get - and has probably been thought up by every dev after their first major dependency conflict. I'm pretty sure distro maintainers know about it too.

So my question is just what the problems are that prevent adoption, even after decades of dealing with the problem, even in the face of growing threats from devs to abandon the distro model altogether.

Fedora project abandons modularity, because nobody needs it. I found the developer, which needs modularity, so he can save the modularity for all of us. I'm politely asking to join the Fedora project and just maintain the solution. Where you found the aggression?

Reply on news.ycombinator.com