When you evaluate nixos/tests/simple.nix, you'll run into an infinite
recursion since 41b140cb25.
The reason is that udisks2 now pulls in gnupg because it now depends on
libblockdev, which in turn depends on volume_key and that depends on
gnupg.
Nevertheless, it's not the real reason, because this only means, that
since gnupg is now pulled into the closure of a basic nixos
configuration the real problem becomes visible:
In nixos/modules/config/no-x-libs.nix there is an overlay which does
something like this:
nixpkgs.overlays = singleton (const (super: {
pinentry = super.pinentry_ncurses;
}));
Now since pinentry_ncurses is already using pinentry.override we get an
infinite recursion because now the pinentry attribute refers to
pinentry_ncurses, which by itself is again referring to pinentry.
This is solved by using the self.pinentry.override instead, so that the
override used by pinentry_ncurses doesn't use the attribute from the
overlay.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
Signed-off-by: aszlig <aszlig@nix.build>
A .la file specifies linker flags to link with the library it describes. Its
"dependency_libs" field lists the libraries that this library depends upon.
This list often contains "-l" flags without corresponding "-L" flags. Many
packages in Nixpkgs deal with this in one of these ways:
- delete .la file [1]
- clear dependency_libs [2]
- add -L flags to dependency_libs [3]
- propagate dependencies [4]
Sometimes "dependency_libs" contain wrong "-L" flags pointing to the "dev"
output with headers rather than to the main output with libraries. They have to
be edited or deleted to reduce closure size [5].
Deleting .la files is often but not always safe [6]. Atomatically deleting as
many of them as possible is complex [7]. Deleting .la files that describe
shared rather than static libraries is probably safe; but clearing their
"dependency_libs" field achieves the same effect with less potential for
unintended consequences. This is the approach that may be enabled for all
Nixpkgs.
[1] 2a79d296d3
[2] c83a530985
[3] 9e0dcf3bd9
[4] 01134e698f
[5] f6c73f1e37
[6] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives
[7] https://github.com/gentoo/gentoo/blob/fb1f2435/eclass/ltprune.eclass
