On Fri, Aug 26, 2022 at 4:57 AM Florian Schmaus <f...@gentoo.org> wrote: > > While then can not be modified, settings made in /usr/lib/systemd/system > can be overridden by the sysadmin by placing a file in /etc/systemd/system. > > I am not aware of a reason why a package manger should install systemd > configuration files under /etc. >
I'd say the biggest use case would be settings that typically require modification that are needed at service launch time. Think of packages that stick stuff in /etc/conf.d for non-systemd settings. An example of this can be found in sys-devel/distcc/files/distccd.service.conf Sure, you could stick that in /usr, and then the user could copy it to /etc (or use systemctl edit). However, since it is something that is basically intended to be edited you can argue that it makes more sense to just stick it in /etc. This also means that if a new setting gets added the user will be made aware via config protection. For a drop-in that changes in /usr the user would receive no notice of this, and the new settings would get merged with theirs or ignored depending on how it was done. For a distro override that wouldn't typically be modified, like integrating one service with another that only service the local host, then maybe /usr would make more sense. Using systemctl edit is also a little awkward due to the way it presents you with the original config at the bottom and you have to copy the stuff you want to modify to the top. I assume it lets you copy comments as well, but it is a bit like opening up two editors and copying from a skeleton file to a new file, vs just editing one in place. Well, except you aren't working between two files but editing at two places in one file, so if your editor doesn't handle split screen well you will scroll around a lot if the file is large. I don't have very strong feelings about this either way, but I can definitely see why things were done the way they're done. I'm not sure if there are any examples of fairly large drop-ins in /etc that we install but I'd probably want to look at one before changing the approach to see if it makes sense. -- Rich
