mirror of
https://github.com/flatcar/scripts.git
synced 2025-10-24 05:41:04 +02:00
8a67dfa986
The systemd.eclass was not finding the systemd pkg-config file to figure out the system unit directory, so it was falling back to a hardcoded default (`/lib/systemd/system`). In one case (when overriding the `default.target` symlink), we tried to fix that by specifying the `PKG_CONFIG_LIBDIR` environment variable, but that still did not help. Using functions from `systemd.eclass` in a systemd ebuild is working only by chance here. This eclass is usually meant for ebuilds that depend on systemd and rely on systemd being already installed in the root filesystem. The functions in `systemd.eclass` that need to figure out some values from systemd's pkg-config file (like system unit directory) assume that systemd is already installed in the root filesystem, which is not the case when we actually are building and installing systemd. To add an insult to the injury, `systemd.eclass` is not using pkg-config directly, but rather a shell script that wraps pkg-config (for example `/usr/bin/x86_64-cros-linux-gnu-pkg-config`). The script clobbers the environment variables like `PKG_CONFIG_PATH` or `PKG_CONFIG_LIBDIR`, which is why overriding them did not work when fixing up the `default.target` symlink. Thus `systemd.eclass` was actually falling back to a hardcoded default value. The only way to control the script is through either SYSROOT or ROOT environment variables. So do so. This fixes merging the installed files into root file system using a newer version of portage. The failure was that systemd build system installs the `default.target` symlink in `/usr/lib/systemd/system` pointing to `graphical.target`, while we later try to override it to point it to `multi-user.target`. But instead of overriding a symlink, we installed a new symlink in `/lib/systemd/system`. Both `/lib` and `/usr/lib` are separate directories in the temporary installation directory, but in root filesystem, both are symlinks pointing to the same directory. Which means that we ended up with two different symlinks in temporary installation directory, and the new portage version could not decide which one to use during the merge into the root filesystem. I'm not sure what old portage version did here, likely worked by chance too.