systemd version the issue has been seen with
246
Used distribution
N/A
I stumbled over 9c5bb20 and realized it's somewhat inconsistent:
- Some of the newly introduced lookups honor a configured
ROOTPREFIX, some don't.
- They hardcode more things than they should, instead of using what meson is configured with (so point to the wrong locations if other configure flags are passed)
- Some locations asked here are really search paths, and files can essentially be read from multiple paths (like tmpfiles). This code returns only a single path string. Maybe we only want to return the location third-party applications are supposed to drop units into?
I'm not really sure on the occasions these methods are being used.
We're talking here about figuring out paths at runtime (which is why we don't want to use pkgconfig). Is this so other external applications know where to drop text files, so it's read by the running systemd?
If so, shouldn't these requests be honored from the running systemd (via some IPC), instead of returning a path baked into whatever libsystemd.so the third-party application is linked against?
systemd version the issue has been seen with
Used distribution
I stumbled over 9c5bb20 and realized it's somewhat inconsistent:
ROOTPREFIX, some don't.I'm not really sure on the occasions these methods are being used.
We're talking here about figuring out paths at runtime (which is why we don't want to use pkgconfig). Is this so other external applications know where to drop text files, so it's read by the running systemd?
If so, shouldn't these requests be honored from the running systemd (via some IPC), instead of returning a path baked into whatever libsystemd.so the third-party application is linked against?