[Nix-dev] Re: Nix and Plash

[Ludovic Courtès]

Hi Mark,

Mark Seaborn <mrs at mythic-beasts.com>
writes:

> ludovic.courtes at inria.fr (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.