This might be a mostly aesthetic problem, but it's been bugging me enough to put a little more effort into resolving it.
In my work environment, we rely very heavily on in-house developed software for Linux workstations and servers, and I've spent some time working on some build tools that provide a consistent build and install process, and reduce per-project boilerplate. I've tried to adhere to existing standards as much as I can. What I have as a result is an install system that puts output files in /usr/local when installing directly from source, and in /usr when packaging (eg. building RPMs). Most of our software is currently installed directly from source, though this will likely change in the future.
So when installing directly, executables go in /usr/local/bin and /usr/local/libexec, libraries in /usr/local/lib64 (this is a RHEL environment), include files in /usr/local/include, and so forth. This works for nearly everything -- .desktop files, icons, pkg-config files, documentation, configuration files, ... it either Just Works or can be easily configured to work, with simple system changes. But I haven't had success with systemd unit files.
My build tools currently place these files in /usr/lib/systemd/system, which is therefore a hard-coded exception to the normal behavior.
Is there a way to configure systemd to also look for service unit files under /usr/local (ie. /usr/local/lib/systemd/system), so the install process can be more consistent, I can avoid the install-time warnings about non-portable hard-coded install target directories, and the files could go to what seems like a more canonically 'correct' location? I'm okay with adding configuration to the system (ideally in the form of drop-ins) to get this to work.
We don't do this much here, but I suppose this question might also apply to software installed to a custom prefix, eg. /opt/MySoftware.
