When, after patching, `configure.ac` is newer than `configure`, the
Makefile will try to regenerate `configure` from `configure.ac`.
While that might usually be desirable, in this case we want to keep
bootstrapping simple and directly use the `configure` from the package
so we can avoid a dependency on automake.
Previously, we used the `-T` parameter to automake to make sure the
timestamps were okay. However, this is brittle when we update: when the
timestamp of the original file changes, and no longer matches the
timestamp of the original file in the patch, `patch` will show a warning
but otherwise continue without updating the timestamp.
This PR changes things so we only patch `configure`, so that will always
have a newer timestamp.
We will update bash-4.4 in a separate PR (but that one has a bigger rebuild
impact so will have to target staging)
Refs #115177
When, after patching, `configure.ac` is newer than `configure`, the
Makefile will try to regenerate `configure` from `configure.ac`.
While that might usually be desirable, in this case we want to keep
bootstrapping simple and directly use the `configure` from the package
so we can avoid a dependency on automake.
Previously, we used the `-T` parameter to automake to make sure the
timestamps were okay. However, this is brittle when we update: when the
timestamp of the original file changes, and no longer matches the
timestamp of the original file in the patch, `patch` will show a warning
but otherwise continue without updating the timestamp.
This PR changes things so we only patch `configure`, so that will always
have a newer timestamp.
Refs https://github.com/NixOS/nixpkgs/issues/115177
mkDerivation does not care about checkPlugins and checkFunctionDirs so let’s avoid polluting the scope.
Also remove installPath argument altogether for the same reason since it is not used at all.
Without this, the bundled zshrc runcom is useless as it assumes that
zsh-prezto is installed in $ZDOTDIR:-$HOME/.zprezto, so it can't find
its entrypoint. Crucially, the home-manager zsh-prezto module uses this
runcom so is broken without this also.
This new option allows for replacing the sourcing of
/etc/fish/nixos-env-preinit.fish with another file, optionally passing
it through `fenv`. The idea here is that non-NixOS users can do
something like
fish.override {
fishEnvPreInit = sourceBash:
sourceBash "${nix}/etc/profile.d/nix-daemon.sh";
}
and this will set up their shell environment for Nix just as though they
were running NixOS.
The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c3490196).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
