On Mon, 18 Sept 2023, 17:43 Nils Kattenbeck, <nilskem...@gmail.com> wrote:
> > Why was the decision taken to put these into /usr/lib/systemd instead of >> > /usr/libexec/systemd/? >> >> That's a Fedoraism. Why would one put something there? >> >> /usr/lib/ is where private arch-dependent package stuff goes. What's >> the rationale for /usr/libexec/ though? >> > > I am not aware of it being a Fedoraism. It is at least also used/populated > on an Ubuntu server I use and documented as part of the filesystem > hierarchy (hier(7)): > https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528 > On Ubuntu we mostly use multiarch locations for shared libraries i.e. /usr/lib/(arch triplet) and /usr/libexec/(native only binaries). To allow us to have additional places for native only and cross only tools. But it is not set in stone. Many gnome, KDE, dbus things ship their binaries or daemons or plugins under /usr/libexec. It sort of makes sense as /usr/lib is confusing when it mixes public libraries, with private libraries and binaries. We can move things around in systemd as well, but on grand scheme of things it is fairly minor tidy up, as neither locations are in default executable paths. /usr/lib is in library search path, which was recently abused to attack remote hosts to load unintended libraries at runtime and clear nx (the recent ssh attack is hallarious and did use systemd to show really fun stuff). So keeping only public libraries in /usr/lib going forward might be a good idea. >
