Re: Update on distro bootstrapping with Guix

[Ludovic Courtès]

Hi,

Richard Stallman <address@hidden> skribis:

>     > I suggest that, for shared libraries, the hash should disregard the
>     > library's current version, and consider only the interface version.
>     > That way, replacement of the shared library won't require any change
>     > in the installed executable.
>
>     I understand the motivation, but that would actually be contrary to the
>     initial design goals, which enable the nifty features mentioned earlier.
>
> I see what you mean -- but this is a high price to pay for those
> benefits.

The bandwidth and disk space cost, in practice, is not unreasonable.

> This suggests we look for a compromise solution that would get most of
> those benefits while avoiding the price.
>
> My previous suggestion is, in effect, one such compromise.  It is to
> do the hashing as now for everything but shared libraries.  For them,
> hash the interface version.  For many users, this compromise may be
> advantageous.

In his thesis, Eelco Dolstra actually proposed a more general solution:
equivalence classes (see Section 6.4 [0]).

However, in production, Nix has always been using the “extensional
model”, which does not support equivalence classes.  There’s an old Nix
branch implementing the model that supports equivalence classes, but
it’s never been used in real life, presumably because it’s way more
complex and brings problems of its own.

> However, by changing the shared library linking mechanism, it could be
> possible to to get essentially all the benefit without the price.  The
> idea is to create a way to specify, for each package, which library
> version to use at run time.
> 
> The idea is that for each shared library interface version, record
> which library versions are present, and have one that is selected.  By
> default, every program that wants that interface version will get the
> selected library version.  However, in the directory for a package
> there can be file that gives a list of shared library names and
> interface version numbers, specififying the library version to use for
> that.
> 
> I think this gets the best of both worlds.  You will be able to update
> shared libraries without reinstalling applications, and most of the
> time everything will use the updated library, but you can make an
> application use an older library version when you prefer.

Well, that would be a significant change in the model.  It’s also likely
to sacrifice several features, such as reproducibility (currently, two
users can compare the behavior of the program, and by checking the path
of that program, they can know for sure whether they are using the exact
same build, bit-for-bit), and rollback (if packages are modified
in-place after an upgrade, how to roll back to the previous
configuration?)

I’m open to improvements to the model, but it’s beyond the goals I had
for Guix, or at least its first milestones.  Any such change is going to
be tricky, and requiring a good understanding of the current model and
alternatives that were already tried.

Thanks,
Ludo’.

[0] http://nixos.org/~eelco/pubs/phd-thesis.pdf