As @oxij points out in [1], this breakage is especially serious because
it changes the contents of built environments without a corresonding
change in their hashes. Also, the revert is easier than I thought.
This reverts commit 3cb745d5a6.
[1]: https://github.com/NixOS/nixpkgs/pull/27427#issuecomment-317293040
This makes those files a bit easier to read. Also, for what it's worth,
it brings us one baby step closer to handling spaces in store paths.
Also, I optimized handling of many transitive deps with read. Probably,
not very beneficial, but nice to enforce the pkg-per-line structure.
Doing so let me find much dubious code and fix it.
Two misc notes:
- `propagated-user-env-packages` also needed to be adjusted as
sometimes it is copied to/from the propagated input files.
- `local fd` should ensure that file descriptors aren't clobbered
during recursion.
What I did was to add two versions of the same package into the same
collection, i.e. ghc-7.0.4 and ghc-7.2.1. I was surprised to see the
build succeed, because there are file collisions between these two. So I
(wrongly) assumed that the collection function was to blame, but in fact
this is a "feature" of nix-env. Apparently, file collision detection
doesn't take place when the user installs two versions of the same
package simultaneously. File collisions are detected only between
different packages!
For example, the command
nix-env -i ghc-7.0.4 ghc-7.2.1-wrapper
is going to fail, but
nix-env -i ghc-7.0.4-wrapper ghc-7.2.1-wrapper
is going to succeed. Maybe I just didn't read the documentation
thoroughly enough, but this behavior sure is unexpected to me.
svn path=/nixpkgs/trunk/; revision=28638
