On 7/16/26 11:40, Andreas Enge wrote:
Am Thu, Jul 16, 2026 at 11:25:19AM +0200 schrieb Hugo Buddelmeijer:
My take-home from Konrad's article: having one package be more 'modern' and
'better' than another, by no means imply that the other package is 'broken'
and needs to be 'fixed' in the name of progress or harmony.
Luckily, Guix by design makes it feasible, desirable even, to have all these
different packages to co-exist harmoniously all the while being
incompatible.
Well, this is true for C with its dynamic libraries, rpath setting in
applications, and sonames (which is why I do not quite feel your pain
with the Python packages for my own work, although it comes with its own
challenges - five versions of fmt, for instance). But it is made terribly
complicated by propagated inputs. Are these handled by your suggestions?
Yes, those incompatibilities are addressed by letting go of the idea
that we should be able to install all Python packages into the same
profile. "Most" would be good enough.
There are old abandoned packages that are not updated but that are still
useful. We can keep those around with older dependencies. It would
just not be possible to use those packages in the same profile with
newer incompatible packages.
But that is fine. Or at least, our job is to ensure that we can still
use those packages, independently in different profiles. That is what
Guix excels at.
Guix would give the users of old software a choice (as in freedom):
using it as-is forever, in which case they can't combine it with the
latest and greatest other packages, or they can maintain it, or they can
abandon it. Other systems force one of those choices.
The drawback to Guix is that Guix would need to provide the 'outdated'
libraries that the software requires. As a compromise we can *choose*
to patch the outdated software. (And in extreme cases, remove them.)
For instance I remember sage being unusable for a few weeks because
it propagated the Python libraries A and B, which in turn propagated
different versions of the Python library C, causing profile collisions.
Yes, the current way we resolve that is claiming that sage or one of
those libraries is broken and needs fixing.
Instead, we would do better by allowing sage to use libraries A' and B'
that propagate the same version of C. Maybe the versions of those
libraries are specifically kept for sage.
That would mean that sage cannot be installed in the same profile as
another application (say Q) that uses library C'. Which is indeed
annoying, but not problematic:
- sage could still be installed with an older version of Q, either also
provided by current Guix, or otherwise through inferiors,
- sage itself could be improved upstream. The design of Guix ensures
that we don't need to do that for them.
Hugo
