Krzesimir Nowak 8a67dfa986 sys-apps/systemd: Fix unit installation
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.
2021-01-29 21:42:31 +01:00
..