This has several advantages:
1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like `${src}/etc/index.html`. Likewise, in
the store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
1. It takes slightly longer to untar at the start of a build.
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.
If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.
It was previously referencing `$bin`, but this package no longer produces a
`bin` output, just `out` and `share`. Updated to make the comparison check a bit
more robust.
Also updated to avoid direct dependency on the `$src` directory out of the nix
store, instead using the processed src setup in the unpackPhase. This provides a
cleaner abstraction between the build/install phase and the input src phase, and
avoids an unnecessary dependency on whether the source disted tarball comes from
`fetchFromGitHub` (in which case it's an unpacked directory) or something like
`fetchurl`. In either case, stdenv is responsible for processing the input `src`
and setting up a clean build dir for us, so we should use that.
This produces an equivalent directory tree, except that the vim plugin is no
longer broken.
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
Last release was in 2012, package is unmaintained and build system is
pretty old, so we can't just replace the ancient gnulib with a newer
version without further hassle.
In the sandbox built for https://nixbuild.net, the coreutils build fails
because a failure in the df skip-rootfs test. The test failure is triggered by
the existance of a rootfs file system. However, I think that the test is faulty,
and I have reported it upstream in
https://lists.gnu.org/archive/html/bug-coreutils/2019-12/msg00000.html.
Disabling the test makes the coreutils build work in the nixbuild.net sandbox,
and I can't think of any negative impact disabling it can have. In normal nix
setups and in the normal nix sandbox, this test is not exercised anyway, since
there is no rootfs visible.
Requires svr4-specific stuff to work around "out of ptys"-error[1],
however this API has been dropped in glibc 2.30 and as the package is
fairly old, there doesn't seem to be an actual fix available.
[1] https://github.com/mjording/ttyrec/pull/2
I don't think there's any situation in which an unwrapped execlineb is
useful -- if you want to use different versions of the execlineb tool
it'll still prefer ones in PATH. At the same time, implementing the
wrapper in this way, as a series of two derivations, meant that we
didn't get stdenv goodness for the wrapper. This meant that, for
example, the wrapper was not stripped, and so execline ended up with
runtime dependencies on gcc and the Linux headers. I don't want to
have to reimplement this sort of stuff when it's already in stdenv,
and so it makes much more sense to create the wrapper in the
mkDerivation call, where all of stdenv's normal magic will find it.
Not sure if I missed something or the issue got fixed later, but it's
not needed anymore to pass a `--build` flag to the configure script on
aarch64.
The autoreconfHooks are still needed for expect and bzip2.
