[Nix-dev] Re: Boost libraries

[Nicolas Pierron]

On Fri, Apr 10, 2009 at 12:48, Marc Weber <marco-oweber at gmx.de> wrote:
>> 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)
>
> ...

Right.  So this may cause a recompilation of the world just to reduce
the memory used on the hard-drive.

> 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.

So, this improve the RAM usage, because the kernel does not have to
load the same library twice.

> Nix solves some issues and causes some different..

As Lluís Batlle  said, I prefer that of wasted disk space/compilation
time, by now.

First, Nix handles the dependencies between packages.  Second,
automatic settings have counter-part which are problematic for
"package testing".

I don't know how you are working, but I often try programs before
either adopting them or removing them.  Compiling other programs in a
different ways only because we want to test a package is an unrelated
waste of CPU time.  Removing duplicated packages from a
user-environment is an optimization and as Knuth said: "Premature
optimization is the root of all evil".

On the other hand we really want to remove duplicated packages.  We
don't have enough feedback yet to decide if this step can be
automatically computed.  An idea could be to report duplicated
dependencies coming from a derivation (by looking at name prefixes).
Reporting duplicated dependencies (in addition to the graph
exportation) is enough for any user to track back the options which
need to be activated to reduce the number of duplicated packages.
Moreover this could be helpful to avoid unwilling dependencies.

In future version, we can imagine to report the minimal set of option
required to reduce the memory foot-print.

So I suggest to goes slowly on this debatable point by just adding a
way to report duplicated packages coming with a derivation (which does
not required to be built).

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.