[Nix-dev] Re: Boost libraries

Marc Weber marco-oweber at gmx.de
Fri Apr 10 12:48:21 CEST 2009


> 2) Scoped Monadic Packages
> 
> Pros:
>  - Allow multiple packages to share a subversion install containing
> all features required.
>  - Multiple scope can be created to handle incompatibilities.
> 
> Cons:
>  - The subversion package (or another) could have a build failure due
> to incompatible options.
>  - Cannot reproduce an installation without installing the same set of
> packages. (or activating each option manually)

Mmh. That's the prolem. Then you do have gentoo with use flags and a
emerge ... world (recompile everything)

Consider this worst imaginable case (Michael Raskin has solved this
differently): the build script. Now consider you've compiler 500
packgaes for your system and then you'd like to install another package
which requires an extra build script extension. Now using scoped monadic
packages would require rebuilding the whole system so that all packages
are based on the new extended build script? I guess this wastes a lot
more time and disk space (unless you run the garbage collector
afterwards.)..

Anyway using this means saying goodby to nix-env -i package and hello to
nix-install-my-environment-describing-all-packages-at-once.

Nice point: You're always up to date.
Bad point: if you just want to install a very small package you
definitely don't want to update everything you've installed to you
profile. But without doing so running the garbage collector doesn't free
much memory. Even if you did recompile all of your user profile packages
you don't get that much cause you'r scope can't (and should never (?) )
include the one of the profile of user x, y and z. So if you allow
different users installing different packages you'll have a lot of
packages anyway.

There is another advantage: if you recompile all of your packages less
different shared libraries have to be loaded. So packages are more
likely to startup fast.

Another way would be improving the way how multiple packages can be
stored on disk. Eg don't use rpath but use env vars. Why? You'll get the
same shared and executable files which can be hard-linked then.

Simple example:
Add an empty line to the builder script. Everything will be recompiled.
You'll get the same results though only differing in the rpaths..
So man page files can be hard linked but neither the shared nor the
executable files. I don't say I'd like to use long LD_LIBRARY_PATH env var
wrappers.. However they would result in less used disk capacity by
/nix/store..

By the way this would make making binary diffs even easier. So
stdenv-updates could be less painfull..

Nix solves some issues and causes some different..

Marc Weber



More information about the nix-dev mailing list