Hi, Richard Stallman <[email protected]> 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
