Hi.This is a follow-up, but it considers a long-term thoughts of mine about nix package management evolution. I'll be glad to read your opinions.
On 01/10/2013 08:26 PM, Vladimír Čunát wrote:
there are external-runtime dependencies (let me call them that), like executables from other packages only run when *executing* something in the package (like firefox plugins). These can be added via wrappers, so in case the external executables are rebuilt you only need to rebuild the wrappers (which is trivial) and not the whole package.
This could also be done with libraries (not used in nixpkgs AFAIK).Since there might be problems with configure scripts, I would do it this way: - use the intensional model of the store (we use extensional AFAIK) [nix-thesis]
=> the hashes will be the same iff the contents is- clear all RPATH records, so rebuilding against another library version usually doesn't change the hash (so the path is re-used!) - wrap all executables to use exactly the library versions we want. We have to cover the whole dependency tree... and as a bonus we can more easily check/ensure that there are not multiple library versions in dependencies of one executable (that's IMHO mostly undesirable).
[nix-thesis] http://nixos.org/~eelco/pubs/phd-thesis.pdfI believe something like the way above would be a very nice improvement in many aspects:
- less disk space, perhaps slightly smaller binary patches- possibility of impure quick re-linking with security updates (without rebuilding) and testing consistency retrospectively by true rebuilding
- perhaps more consistent library sets - probably easier purity checking (via content-addressable store)BTW, a not-so-much-related idea: we could test purity by randomly trying to build the same derivation on another machine.
Vlada
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
