Unfortunately the `readFile`/`writeText` functions forces realisation of
the eclipse package at evaluation time. By creating the configuration
file inside the build command we avoid realisation until installation.
See http://nixos.org/nixpkgs/manual/#sec-package-naming
I've added an alias for multipath_tools to make sure that we don't break
existing configurations referencing the old name.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Previously, version 0.4.9 was a tarbomb and in version 0.5.0 this
fortunately isn't the case anymore so we don't need to set sourceRoot by
ourselves.
I've also moved the definition of makeFlagsArray to the attribute
makeFlags, because we can use $(var) to substitute shell variables
within make.
The references to /lib/udev/scsi_id no longer exist in version 0.5.0 and
it seems that libudev is used directly.
Nevertheless, there are still references to FHS paths such as /var/run,
/etc/multipath.conf and /etc/multipath but these are only relevant at
runtime and can be configured to point to a different path elsewhere.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
By default, GPGME tries to search in $PATH for the gpg and gpgconf
binaries. This has the downside, that the library won't work by its own
and needs to have GnuPG in systemPackages or the user environment.
I've stumbled on this while working on one of the dependencies of
nixos-assimilate and nixpart (volume_key), where the testing environment
didn't come with GnuPG in $PATH and thus the tests have failed.
After testing this with a few programs using GPGME, I haven't found any
weird behavior in conjunction with the GnuPG agent.
However one possible implication could be that if the GnuPG used in
$PATH (and the config files in the user's home directory) should be
vastly incompatible, it could lead to failures.
In practice however, the GnuPG1/2 versions pretty much seem to stay
compatible within their major releases so it shouldn't pose a problem.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
