Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
Commit 093cc00cdd9d8cf31ecce5bc1dd3645c460a1b98, sets the STRIP environment
variable by default, but this confuses the mdadm Makefile, which uses STRIP as a
flag to `install'.
Would be just mdadm: 3.3.4 -> 4.0, but it doesn't look like there are
urgent bugfixes, and it is a major release, and wrong RAID handling
kills data, so let's let the early adopters test it a bit.
The updates we had in the past (7719f7f and 1faf610) broke the mdadm
installer test and systems in the wild using mdraid because newer mdadm
versions contained a self-referenc to its own store path.
Instead of putting a big warning about updating in the package
expression, let's just add allowedReferences so the build immediately
fails if there is a self-reference.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's use makeFlags directly instead of stitching together a
makeFlagsArray in preBuild.
This should make the expression much more readable and clean.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Okay, this update is a bit more tricky and the patch I've included is
not very nice to be honest.
So the patch causes "mdadm --udev-rules" to search for the right store
path using /proc/self/exec. This has the disadvantage that we could end
up having /run/current-system/bin/mdadm in the rule file.
But on the other hand, when we're on NixOS, we don't need to use that
command *at*all*, so we should be safe.
The patch also sets BINDIR to /sbin, which causes the included rule and
systemd files to not work out of the box on NixOS. But we have a
substituteInPlace where we do rewrite /sbin/mdadm to the right store
path in our udev rule generator, so that shouldn't be an issue.
I've tested this using the mdraid installer test and it succeeded.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 7719f7f23b8ad754d3a5916f5a218110c89eb69f, again!
It prevents systems from booting, for two reasons:
* The initrd size is going to explode, but I think this is not the
REAL issue. We had that in 666cf99 already, which reverted this
update already.
* Another reason I don't yet know, which is the REAL issue. We need to
investigate and fix that before attempting another update.
Because of that I've also added a small comment before the src attribute
to prevent further updates like this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 1faf6106c3fc5890297ad6c8e26b572d91dede5a. It
causes the size of the initrd to explode from ~6 MB to 19 MB:
http://hydra.nixos.org/build/15728196
The reason is that mdadm now contains a self-reference:
$ strings ./result/sbin/mdadm | grep /nix/store
...
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="%s", ENV{ID_PATH}=="%s", RUN+="/nix/store/y1ap6va0av6jhxf7ddnr8vdwxd7b44gd-mdadm-3.3.2/sbin/mdadm --incremental $env{DEVNAME}"
ACTION=="add", SUBSYSTEM=="block", ENV{ID_PATH}=="%s", RUN+="/nix/store/y1ap6va0av6jhxf7ddnr8vdwxd7b44gd-mdadm-3.3.2/sbin/mdadm --incremental $env{DEVNAME}"
/nix/store/y1ap6va0av6jhxf7ddnr8vdwxd7b44gd-mdadm-3.3.2/sbin/mdmon
(Previously, it referred to /sbin/mdadm.) This causes mdadm, glibc and
linux-headers to be added to the initrd.
