Result of nixpkgs-review pr 105850 run on x86_64-linux 1

Hmm, both main suspects (tracker wrapper changes and meson bump) are already on master so it must be something else.

Looks like there is a regression in systemd pkg-config variables, this will break many packages:

--- /nix/store/6fkka81sc5w9ip4y5mnlw56w73jhzs5f-systemd-246.6-dev/share/pkgconfig/systemd.pc
+++ /nix/store/9dr7dzc4lywln6swpma98gwppx688mr0-systemd-247-dev/share/pkgconfig/systemd.pc
@@ -1,4 +1,4 @@
-#  SPDX-License-Identifier: LGPL-2.1+
+#  SPDX-License-Identifier: LGPL-2.1-or-later
 #
 #  This file is part of systemd.
 #
@@ -11,8 +11,8 @@
 # considered deprecated (though there is no plan to remove them). New names
 # shall have underscores.
 
-prefix=/nix/store/iyayrhagfqccsrfzw2fqs2q8n4b6h2lg-systemd-246.6
-root_prefix=/nix/store/iyayrhagfqccsrfzw2fqs2q8n4b6h2lg-systemd-246.6
+prefix=/usr
+root_prefix=/nix/store/n9lzlyhq8d9gv9hdi0gay1plmzlz70j9-systemd-247
 rootprefix=${root_prefix}
 sysconf_dir=/etc
 sysconfdir=${sysconf_dir}
@@ -26,10 +26,10 @@
 systemd_system_preset_dir=${rootprefix}/lib/systemd/system-preset
 systemdsystempresetdir=${systemd_system_preset_dir}
 
-systemd_user_unit_dir=${prefix}/lib/systemd/user
+systemd_user_unit_dir=/usr/lib/systemd/user
 systemduserunitdir=${systemd_user_unit_dir}
 
-systemd_user_preset_dir=${prefix}/lib/systemd/user-preset
+systemd_user_preset_dir=/usr/lib/systemd/user-preset
 systemduserpresetdir=${systemd_user_preset_dir}
 
 systemd_system_conf_dir=${sysconfdir}/systemd/system
@@ -48,7 +48,7 @@
 systemd_system_generator_dir=${root_prefix}/lib/systemd/system-generators
 systemdsystemgeneratordir=${systemd_system_generator_dir}
 
-systemd_user_generator_dir=${prefix}/lib/systemd/user-generators
+systemd_user_generator_dir=/usr/lib/systemd/user-generators
 systemdusergeneratordir=${systemd_user_generator_dir}
 
 systemd_system_generator_path=/run/systemd/system-generators:/etc/systemd/system-generators:/usr/local/lib/systemd/system-generators:${systemd_system_generator_dir}
@@ -63,7 +63,7 @@
 systemd_shutdown_dir=${root_prefix}/lib/systemd/system-shutdown
 systemdshutdowndir=${systemd_shutdown_dir}
 
-tmpfiles_dir=${prefix}/lib/tmpfiles.d
+tmpfiles_dir=/usr/lib/tmpfiles.d
 tmpfilesdir=${tmpfiles_dir}
 
 sysusers_dir=${rootprefix}/lib/sysusers.d
@@ -78,7 +78,7 @@
 modules_load_dir=${rootprefix}/lib/modules-load.d
 modulesloaddir=${modules_load_dir}
 
-catalog_dir=${prefix}/lib/systemd/catalog
+catalog_dir=/usr/lib/systemd/catalog
 catalogdir=${catalog_dir}
 
 system_uid_max=999
@@ -99,4 +99,4 @@
 Name: systemd
 Description: systemd System and Service Manager
 URL: https://www.freedesktop.org/wiki/Software/systemd
-Version: 246
+Version: 247

cc @flokli @FRidh

I don't think that will break anything. Those PKG config variables are there to install Systemd units to the right place. Which doesn't make any sense in NixOS as it points to a path that is immutable and in NixOS instead we use the module system to install Systemd units.

Edit: ah but the prefix might matter. I see. As that isn't interpolated anymore Does NixOS modify that in third-party pkg-configs?

Edit: ah but the prefix might matter. I see. As that isn't interpolated anymore Does NixOS modify that in third-party pkg-configs?

Normally, projects are expected to override prefix to their own prefix in the pkg-config variables, see https://www.bassi.io/articles/2018/03/15/pkg-config-and-paths/. Of course that is not possible when the prefix is hardcoded.

systemd's pkgconfig has changed in systemd/systemd@6e65df8, which was part of systemd/systemd#17009. If I read https://www.bassi.io/articles/2018/03/15/pkg-config-and-paths/ and pick

If you are defining a path inside your project’s pkg-config file, always make sure you’re using a relative path!

out of this… Should we open an upstream issue?

Yes, we should consider this an upstream regression.

This is important for two reasons:

• Installing to non-FHS package-specific prefixes for distros with immutable roots like NixOS. Those cannot use /usr and it is their responsibility to ensure systemd can find the service files.
• Installing to local path for development purposes. This is a compromise between running program from a build directory and running a program fully installed to system prefix. You will not want to write to your system prefix in that use case.

In either case you want to support overridable prefix so a project can be successfully installed as per https://www.bassi.io/articles/2018/03/15/pkg-config-and-paths/. Hardcoding the prefix means projects will no longer have reason (or a sensible way) to install the data relative to prexix (which will be /usr anyway on modern FHS distros) and it will force users wanting to use one of the aforementioned use cases to patch each project’s build system.

I reverted the said commit for now. And upstream solution might take more time than I would want to block staging for: #106044

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 105850 run on x86_64-linux 1

@Kiwi the pkg-config build issue is resolved

oh yeah I built it on staging/staging-next/and master last night but forgot to comment