targetPlatform is the platform the current package's programs will
produce binaries for — only relevant for compilers and
similar. hostPlatform is the platform the current package's programs
will run on.
The incorrect use of targetPlatform meant that anything that tried to
link to it (like cryptsetup) would fail to build when it was used as a
native build input for a cross-compiled Musl derivation.
Fixes: 2cc29125a7 ("lvm2: package 2.02.x for musl")
Alpine's version of the first patch no longer applied, because we're
on a newer lvm2 version.
The fixes in both of these patches are either Musl-specific, or
shouldn't negatively affect Glibc, so change to applying them
unconditionally so they don't bitrot in future.
e606e4d6a9 ("lvm2: musl patches from alpine") added all these patches
from Alpine to fix Musl builds, but one doesn't actually seem related
to Musl. The Alpine issue[1] that led to its introduction links to a
Gentoo issue[2] about the same thing on Glibc.
We shouldn't be applying a fix for a non-libc-specific bug only to
Musl builds, and if this was going to be an issue for us we'd expect
to have seen it on Glibc by now. It's more likely that it's been
fixed in the meantime.
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/3107
[2]: https://bugs.gentoo.org/335492
thin-provisioning-tools has a _huge_ closure size (hundreds of
megabytes) and the only reference in the output of the lvm2 package is a
_comment_ in the etc/lvm.conf
The lvm2 package thus does not seem to depend on thin-provisoning-tools
in any way.
Reverts 9326a89910
thin provisoning is broken with or without this change:
https://github.com/NixOS/nixpkgs/issues/15516
A proper fix is here:
https://github.com/NixOS/nixpkgs/pull/46541
References:
$ nix why-depends nixpkgs#lvm2 nixpkgs#thin-provisioning-tools
/nix/store/n7zwwxi0ihjks7qk9bq5lbkniligfcqc-lvm2-2.03.11
└───etc/lvm.conf: …_check_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-prov>
→ /nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0
$ ag thin-provisioning-tools --search-binary
etc/lvm.conf
1093: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1095: # thin_check_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/thin_check"
1100: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1102: # thin_dump_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/thin_dump"
1108: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1110: # thin_repair_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/thin_repair"
1155: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1157: # cache_check_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/cache_check"
1162: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1164: # cache_dump_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/cache_dump"
1170: # (See package device-mapper-persistent-data or thin-provisioning-tools)
1172: # cache_repair_executable = "/nix/store/w5an38q6byfr1sihks66srbqdii9hnsd-thin-provisioning-tools-0.9.0/bin/cache_repair"
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
https://github.com/lvmteam/lvm2/blob/v2_03_11/WHATS_NEW
[VDO](https://github.com/dm-vdo/vdo) support is built by default now,
but is disabled in nixpkgs, because it can't find `vdoformat`.
AFAICT the kernel support for that still isn't upstream and it still
seems kind of experimental, so I'd just ignore that for now and add it
once it's either upstream of if anyone actually wants to use it.
- use installTargets again ("install", and
"install_systemd_{generators,units,configuration}" when udev is not
null)
- The call to the blkid binary in lvm2's 13-dm-disk.rules file
disappeared (so we don't need to patch in blkid anymore).
lvm seems to rely on udev's internal blkid functionality.
- Call /run/current-system/systemd/bin/udevadm instead
of ${systemd}/bin/udevadm in the lvm activation generator.
This is not necessary to break the dependency cycle (as we don't use
that file when building without udev), but a good idea anyways -
We want to trigger the udevadm of the current system, not the one
that lvm was built with.
* Revert "lvm2: enable parallel building"
This reverts commit 494d2deebf.
I am getting
```
gcc: error: ../../device_mapper/libdevice-mapper.a: No such file or directory
```
