Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
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.
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
This reverts commit fb6d63f3fd.
I really hope this finally fixes#99236: evaluation on Hydra.
This time I really did check basically the same commit on Hydra:
https://hydra.nixos.org/eval/1618011
Right now I don't have energy to find what exactly is wrong in the
commit, and it doesn't seem important in comparison to nixos-unstable
channel being stuck on a commit over one week old.
I *want* cross-specific overrides to be verbose, so I rather not have
this shorthand. This makes the syntactic overhead more proportional to
the maintainence cost. Hopefully this pushes people towards fewer
conditionals and more abstractions.
This prevents systemd and by extension a zillion other packages from
having Python 2.7 in their closure. For example, the closure of
systemd dropped from 133 MiB to 85 MiB.
This allows all utilties to at least run, though most still fail
because they expect to be able to read a non-existent config file.
Also, aa-notify refuses to run due to a self-check on the filename,
which cannot be preceded by a '.'. This has to be patched or we
need to set PERL5LIB some other way.
This was untested and didn't function without a dbus patch which wasn't
applied to the system dbus package, so it wasn't used at all.
Also, it creates a weird cyclic dependency if we want systemd to depend
on libapparmor (for AppArmorProfiles= support), because libapparmor then
wants dbus, and dbus wants systemd. Oof.
Luckily, this feature and whatnot will probably all be irrelevant in the
glorious kdbus-based future, and the dbus patches aren't even upstream I
think. So we can just drop it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
