3 ms·

Different versions of the same libraries for different applications is still the same problem. Fundamentally developers are writing software that distributors a

by zanny 11y ago

Different versions of the same libraries for different applications is still the same problem. Fundamentally developers are writing software that distributors and integrators do not want to actually ship. There are two independent circumstances to that, though. Either the developer does not deserve downstream trust because they abuse their users by breaking their APIs, ABIs, or UX's without due notice or process. This is how things were in the early 90s when Debian first started and the original crop of distributions emerged - the mindset was, of course as a distributor I have to assume responsibility for packaging and integrating all the software I ship, and thus of course I cannot track the individual releases of everything I include while making sure everything still works. That is insane, and no software distributor in the world does that. The other circumstance is when developers do deserve trust but are not given it, as is the case in Debian, or why KDE needed the Neon project. Or when they want to assume the responsibility on their own, which no Linux distro provides adequate means to directly support users.

digi_owl 11y ago
From where i sit, what seems to block most distributors from upgrading is the rigidity of their tradition package managers when dealing with multiple versions. Thus they are reluctant to adopt new version of something, because the dependency chain may force a update of a large part of a installed system. A package manager that can handle multiple version frees them from this worry, without the admin of a system having to trawl every "container" if a lib is found to be vulnerable (a very real possibility with the likes of xdg-app, and somewhat akin to Windows "dll hell").
- zanny 11y ago
  In general, if new versions of libraries are breaking the ABI or API, the library developer needs to be thoroughly scolded. We are well capable and have the necessary workflows to create ABI and API stable feature releases. If vendors chose not to use these practices to create stable software, we need to criticize them and work to replace developers who don't respect their users enough not to break everything on every release. Arch, for example, has clang3.5 and clang available because 3.7 was an ABI break. It has gstreamer 0.10 and 1.0 as separate packages because it was an API break. These projects respect these design constraints and should be trustworthy, and notify downstream of breaking issues like that well in advance so packagers can avoid repackaging upgrades expecting smooth transitions. But its unfair to users and developers to use carte blanche policy of freezing everything because some bad apples cannot maintain ABI/API stability.
  - digi_owl 11y ago
    A new version is about more than APIs and ABIs. It may introduce a new feature, or it may fix a bug that previously needed a nasty workaround or made something practically impossible while present.

by zanny 11y ago

digi_owl 11y ago

From where i sit, what seems to block most distributors from upgrading is the rigidity of their tradition package managers when dealing with multiple versions. Thus they are reluctant to adopt new version of something, because the dependency chain may force a update of a large part of a installed system. A package manager that can handle multiple version frees them from this worry, without the admin of a system having to trawl every "container" if a lib is found to be vulnerable (a very real possibility with the likes of xdg-app, and somewhat akin to Windows "dll hell").

zanny 11y ago
In general, if new versions of libraries are breaking the ABI or API, the library developer needs to be thoroughly scolded. We are well capable and have the necessary workflows to create ABI and API stable feature releases. If vendors chose not to use these practices to create stable software, we need to criticize them and work to replace developers who don't respect their users enough not to break everything on every release. Arch, for example, has clang3.5 and clang available because 3.7 was an ABI break. It has gstreamer 0.10 and 1.0 as separate packages because it was an API break. These projects respect these design constraints and should be trustworthy, and notify downstream of breaking issues like that well in advance so packagers can avoid repackaging upgrades expecting smooth transitions. But its unfair to users and developers to use carte blanche policy of freezing everything because some bad apples cannot maintain ABI/API stability.
- digi_owl 11y ago
  A new version is about more than APIs and ABIs. It may introduce a new feature, or it may fix a bug that previously needed a nasty workaround or made something practically impossible while present.