On Apr 21, 2010, at 6:51 PM, David Soergel wrote: > Is there some compelling reason why the location of the nix store is fixed at > compile time, and why nix-push/nix-pull can only work among machines that > agree on the location of the store? >
Sure -- FHS and "Have it your own way!" paths lead to complexity for no important gain. Go read D.J. Bernsteion's reasoning with (the very in your face, ymmv) the restrictive qmail licensing. If you read through http://cr.yp.to you will also find djb's package management proposal based on "/package" hardwired much like "/nix/store" is hard-wired. No instances, and no "functional package management", but the same basic idea: Path prefixing breaks software needlessly. > I'm guessing the trouble is that the .drv files contain absolute paths, so > the closure hash is sensitive to the store location. But all of the paths > begin with the store path anyway, so why not just keep them relative? Then > the store location could be provided at runtime, could be in a user's home > directory (not requiring root access as "/nix/store" does), and channels > would work anyway, since the derivation hashes would be consistent. > Yep. But because there's _ALWAYS_ a Nix instance attached to all data in "/nix/store", there's literally no reason why the "/nix/store" prefix matters much. Its the instance hash, not the path prefix, that is essential. (aside, total guesstimate) You likely (untested, I haven't yet looked) can achieve "/nix/store" prefix independence by generating your nix instances slightly differently, without the "/nix/store/" prefix, or substituting any token for "/nix/store" everywhere you try to generate a Nix instance. I doubt the plain test hashes generated by nix-hash care too much. The hack to substitute a token for the literal "/nix/store" prefix is very not hard, but there's likely some deeper reasons why "/nix/store" _MUST_ be used as a prefix. But I digress, there's simply no reason imho to substitute a token for the literal "/nix/store" prefix token, it adds a huge amount of complexity for no demonstrable gain. Disclaimer(s): I am a djb (and increasingly, Nix+Eelco ;-) fan-boy. JMHO, YMMV, everyone's does. > That seems to me like the conventional way to do things-- what am I missing? > Thanks for any insights, > hth 73 de Jeff _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
