For the same reason we disable shebang patching in these derivations,
we want to disable the patching of libtool scripts stdenv does.
Otherwise, libtool will install scripts into other packages that are
already "fixed", but for the environment libtool was built in. These
scripts won't be fixed properly by stdenv anymore, because it will
think they were already fixed.
This fixes the build of pkgsStatic.libwebp, which was failing because
its libtool script wasn't being patched properly.
Another problem "fixing" the scripts in the libtool package would
cause is that package tarballs generated on NixOS would contain
libtool scripts that didn't make sense on other distros.
I've tested this change by building pkgsStatic.libwebp, which now
works, as well as by testing the build of the bootstrap files for
mips64el to make sure that didn't regress from 97c43828fb
("fixLibtool(): patch ./configure, add `file` to common-path.nix").
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
Some packages have a runtime dependency on libltdl, but shouldn't
depend on the rest of libtool (which in turn depends on binutils and
other stdenv tools). For example, splitting off libltdl cuts about 35
MiB from the closure of PulseAudio.
linking path), and with this achieved bash being cross-compilable.
I fixed the few expressions involved in bash building, so they have well stated
native and non-native inputs.
I also tried to cross-build guile, and with this I found a problem in the
actual cross-gcc: it calls the binutils ld, instead of the ld wrapper. This
way, the programs/shared_libraries don't get the proper -rpath.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18497
