Re-inventing distro mechanisms

Posted Jul 24, 2025 6:26 UTC (Thu) by callegar (guest, #16148)
In reply to: Re-inventing distro mechanisms by raven667
Parent article: Reinventing the Python wheel

What is practically happening is that for some packages what would be the "major" version number, i.e., the number indicating non-backward compatible API changes in semantic versioning becomes a part of the package name.

So you get `foo1`, `foo2` and `foo3` rather than `foo` and you can have `foo1`, `foo2` and `foo3` coexist. This clearly does not let you *share state* between `foo1` and `foo2`. However, if the APIs are different the very idea of *sharing state* becomes scary.

Obviously, this requires discipline in package naming. But I think it would help a lot the work of distros if more packages followed this approach.

Re-inventing distro mechanisms

Posted Jul 24, 2025 10:50 UTC (Thu) by farnz (subscriber, #17727) [Link] (4 responses)

There's two problems with this approach (it's been tried before, and doesn't help distros):

Distros don't want to package foo1, foo2 and foo3. They want to just package a single maintained version, ideally, but can compromise if there are multiple maintained versions. However, in practice what seems to happen is that foo1 gets abandoned by its upstream, foo3 is the only maintained version, and the distro is now on the hook for pushing all the packages that depend on foo to stop using foo1 or foo2. We've seen this with, for example, GTK+, where GTK+ major versions can coexist, and the work of telling projects to move to a supported version of GTK+ has entirely fallen on the distros.
The same discipline required from foo's developers to ensure that you cannot have different major versions sharing state is also the discipline needed to do things like glibc's versioning linker script. Otherwise, you get things like "we read /etc/foo/config" in both foo1 and foo3, but foo's developers forget that a particular key had a meaning in foo1, and reuse it for a different meaning in foo3 - after all, no-one maintains foo1 any more, so no-one remembers it that well.

This pushes towards the glibc solution (one version, but with backwards compatibility), rather than parallel installability - not least because parallel installability leads towards an NP-complete problem for the packaging team trying to minimise the number of versions of foo that they maintain in the distro.

Re-inventing distro mechanisms

Posted Jul 25, 2025 4:45 UTC (Fri) by donald.buczek (subscriber, #112892) [Link] (3 responses)

> Otherwise, you get things like "we read /etc/foo/config" in both foo1 and foo3, but foo's developers forget that a particular key had a meaning in foo1, and reuse it for a different meaning in foo3

Exactly, the system that has long been chosen for Unix-like operating systems sorts files according to function (/usr/bin, /etc, ...).

You can get quite far with $PREFIX installations and wrappers, but it's ugly and opaque. I sometimes think that a system that always bundles software in name-version-variant directories and supports the dynamic networking of these components as a core principle would be better from today's perspective.

Re-inventing distro mechanisms

Posted Jul 25, 2025 7:22 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

> I sometimes think that a system that always bundles software in name-version-variant directories and supports the dynamic networking of these components as a core principle would be better from today's perspective.

To me that feels just like pushing the problem onto the user. The complexity is all still there, the distro just does not have to care so much about it but the user who wants to use the components together still does and has to constantly make choices related to that.

Re-inventing distro mechanisms

Posted Jul 26, 2025 6:14 UTC (Sat) by donald.buczek (subscriber, #112892) [Link] (1 responses)

But the user would still be free to run a simple command or use ./configure without selecting specific version or variants of existing software and the system would assume the single recommended version or variant.

The user, acting as an admin, would still be able to install new versions and the distribution-provided package manager would analyze the dependencies. It would just not try to resolve this to a result in which each package can only exist once. It might keep other/older variants around which are required by other packages. It might support some kind of diamond dependencies, too.

The basic difference would be, that packages go into their own file system tree so that they don't conflict with each other if multiple variants of the same package are wanted or needed.

Re-inventing distro mechanisms

Posted Jul 26, 2025 10:59 UTC (Sat) by farnz (subscriber, #17727) [Link]

This begins to sound like a reinvention of NixOS and similar distributions, which puts every package into its own prefix, and can support just about any dependency setup you care about as a result.