3 ms·

Nope, It is partially right. There already exist mechanics like soname to differentiate libraries from each other. Package managers do not take this into acco

Nope, It is partially right. There already exist mechanics like soname to differentiate libraries from each other. Package managers do not take this into account, and insist on there only being one version present pr package name. That said, containers are shooting twee twee birds with AA guns.

xorcist 10y ago
> insist on there only being one version present pr package name That's a partial truth, at best. It is common for multiple versions of popular libraries to be installed at the same time. The whole of Debian or Red Hat isn't necessarily compiled with the same libcpp or Boost, for example, and that's expected. Some software run on Python 2 and some on 3. The packager would need to make sure they don't conflict, but Linux handles different sonames just fine and as long as you separate module paths you'll be just fine.
- digi_owl 10y ago
  No it is not. If you want to install two minor versions of glib side by side, it can be done on the soname level (not to say that it is a smart idea, because Gnome devs are crap at keeping API stable). But it can't be done on the package level without playing musical chairs with package naming to work around collisions.
  - snuxoll 10y ago
    This is primarily why Debian and derivatives use the so version in the package name. Fedora is designed on the assumption you'll only ever have one version of a library installed and everything is built against it, special cases then get made for compat packages as needed.
    - digi_owl 10y ago
      Sadly more and more dev time is spent with Fedora as the target, leading to massive myopia. This while Debian has to adopt more and more Fedora-isms because they do no longer have the man hours to go their own way.
      - snuxoll 10y ago
        Well, even though Debian supports this I rarely see it used to install multiple so's side-by-side. Fedora will let you do it, but the entire development process tries to avoid compat libraries where possible (you are supposed to send a message out to the mailing list if a package you maintain is getting a soname bump so others that depend on it can rebuild during the rawhide cycle, this stops being an issue once Beta hits since versions get locked down).

xorcist 10y ago

> insist on there only being one version present pr package name That's a partial truth, at best. It is common for multiple versions of popular libraries to be installed at the same time. The whole of Debian or Red Hat isn't necessarily compiled with the same libcpp or Boost, for example, and that's expected. Some software run on Python 2 and some on 3. The packager would need to make sure they don't conflict, but Linux handles different sonames just fine and as long as you separate module paths you'll be just fine.

digi_owl 10y ago
No it is not. If you want to install two minor versions of glib side by side, it can be done on the soname level (not to say that it is a smart idea, because Gnome devs are crap at keeping API stable). But it can't be done on the package level without playing musical chairs with package naming to work around collisions.
- snuxoll 10y ago
  This is primarily why Debian and derivatives use the so version in the package name. Fedora is designed on the assumption you'll only ever have one version of a library installed and everything is built against it, special cases then get made for compat packages as needed.
  - digi_owl 10y ago
    Sadly more and more dev time is spent with Fedora as the target, leading to massive myopia. This while Debian has to adopt more and more Fedora-isms because they do no longer have the man hours to go their own way.
    - snuxoll 10y ago
      Well, even though Debian supports this I rarely see it used to install multiple so's side-by-side. Fedora will let you do it, but the entire development process tries to avoid compat libraries where possible (you are supposed to send a message out to the mailing list if a package you maintain is getting a soname bump so others that depend on it can rebuild during the rawhide cycle, this stops being an issue once Beta hits since versions get locked down).