Re-inventing distro mechanisms

Posted Jul 25, 2025 4:45 UTC (Fri) by donald.buczek (subscriber, #112892)
In reply to: Re-inventing distro mechanisms by farnz
Parent article: Reinventing the Python wheel

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