Hi Mark, Mark Seaborn <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) wrote: >> He he, sure you can do anything with `.debs', provided you are careful >> enough. The thing is, a Debian `control' file names dependencies using >> human-readable and human-assigned names, such as `libpoppler0'---it does >> *not* name dependencies using hashes. Thus, a `control' file alone is >> ambiguous because it depends on a naming context provided by the >> `Packages' file. > > I view the dependendies in the "Depends" field in the control file as > being more like interface dependencies than implementation > dependencies. Yes, that's what they are, and *only* that. >> Under NixOS, `evince' refers unambiguously to the very `libpoppler.so.0' >> that was used at build-time (through its `RPATH'). The corollary is >> that NixOS does not exploit ABI-compatibility at all: when `libpoppler' >> is upgraded, `evince' keeps using the old `libpoppler', or you have to >> rebuild `evince' to use the new one---but that is a deliberate choice. > > I would prefer to be able to choose between: > a) running the existing Evince with the old libpoppler.so.0 > (while other executables can use the new libpoppler.so.0) > b) running the existing Evince with the new libpoppler.so.0 > (while other executables can use the old libpoppler.so.0) > c) building and running a new Evince with the new libpoppler.so.0 > > I would not expect that building and linking against different > versions of a library that are accidentally ABI-incompatible would be > a common source of problems. It seems more likely that bugs are > removed or introduced in new versions of a library without the ABI > changing, and that this would be a more common source of problems. > > From my point of view, having worked on a project (Plash) which > involves changing libraries underneath applications, it seems like a > bad trade-off to not support (b) and to require (c) instead. Again, that's a deliberate choice. The idea is to express dependencies in terms of implementations, not in terms of interfaces, so that it's easier to reproduce the exact behavior of an application---something APT and friends aren't very good at. I'm sure Eelco would express it better than I do. > From the "Secure Sharing" paper, it seems Nix has a concept of > packages being equivalent if they were built from the same input even > if the outputs were not exactly identical because the build is not > completely deterministic. As I understand it, hash substitution is > used to substitute references to packages that are build-equivalent > but not identical, so it's not just used to deal with self-reference. Yes, right, but I'm not sure how much this is used in practice. Most packages are built fully deterministically and do not defer from one build to another, it seems. Thanks, Ludovic. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
