Based on the information available, systemd is violating Fedora Packaging Guidelines by placing compiled executables in /usr/lib/%{name}/ for all architectures as opposed to using %{_libdir}/%{name}. Please file a bug against systemd, and if they do not resolve the issue, then escalate it to FESCo.

To defend our position:

We don't "violate" the misguided and broken Fedora recommendations, we just intentionally "ignore" them. And we will continue to do so. The option that we change the install location just does not exist, it is a de-facto Linux API, and in no way a distro decision to make.

This is really disappointing, they are upstream-ignorant, against established practice, and they actively sabotage our intention to minimize the Linux distro balkanisation. Someone please wake up and start to think about the impact of these non-sensical rules and the damage they cause for the bigger picture of the Linux ecosystem.

These rules are not only wrong, they are also 100% Fedora-only, which is a clear hint that something might be wrong here. We need less differences between the distros and not more, so please fix them. Thanks!

One potential constructive path: I'd personally consider allowing /usr/lib/%{name} for items that are intentionally not multilib'd (but something like this has yet be proposed formally).

%{libdir} has a few valid use cases, like for binaries which are directly bundled with a shared object, like a setuid helper hidden behind an API. But this should be the _exception and not the rule.

We support compat-arch and not multi-arch, and unless someone fixes the multi-arch part of bin/, and we switch to a full multi-arch scheme, which I personally don't think is worth the trouble, we should treat binaries as isolated and compatible things, that are just installed in lib/; just like all other public executables are installed in bin/ and not in bin64/. There is no distinction between bin/foo and lib/bar/foo, other than the visibility of them; stuff in lib/ is not in $PATH. There is no need to come up with needlessly different packaging rules here.

/usr/lib/%{name} is the upstream recommended default, and there is no indication that this will change in the near future. Libexec/ should be phased out over time, and /usr/%{_libdir}/%{name} should only be the exception for the few tools where it makes things easier to support.

Kay, you keep saying this ("/usr/lib/%{name} is the upstream recommended default"), but you seem to be trying to speak for all upstreams.

The GNU Coding standards do not reflect this:

"The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you are using Autoconf, write it as ‘@libexecdir@’.)

The definition of ‘libexecdir’ is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under ‘$(libexecdir)/package-name/’, possibly within additional subdirectories thereof, such as ‘$(libexecdir)/package-name/machine/version’."

http://www.gnu.org/prep/standards/standards.html

The Filesystem Hierarchy Standard does not specify it at all.

So, unless you can provide some sort of standard that I am unaware of, I would appreciate it if you'd stop saying things are the "upstream recommended default", except for things where you are speaking for yourself as the upstream for a specific project.

We don't "violate" the misguided and broken Fedora recommendations, we just intentionally "ignore" them.

Yeh, so that's the same thing ... except for people not you.

And we will continue to do so.

It's nice to see co-operation with Fedora.

The option that we change the install location just does not exist, it is a de-facto Linux API, and
in no way a distro decision to make.

I find it hard to believe you were stupid enough to make /usr/lib/systemd part of the API, in 2010.

These rules are not only wrong, they are also 100% Fedora-only.

Yeh, distro. specific policies are like that ... distro. specific. You can help change the policies if you think they are wrong ... but you know this, because you already tried for this specific case even:

https://fedorahosted.org/fpc/ticket/139

...and didn't argue your case well, because it wasn't approved.

http://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibexec

"Either practice is now acceptable, but each application must choose one way or the other to organize itself."

So, systemd chose "/usr/lib/systemd", which is acceptable for FHS >= 2.3.

Also "/usr/lib/systemd" does not only contain executables and it would be nonsense and even not allowed by FHS3.0 to split those out in "/usr/libexec/systemd".

Replying to [comment:5 spot]:

Kay, you keep saying this ("/usr/lib/%{name} is the upstream recommended default"), but you seem to be trying to speak for all upstreams.

I speak for the coordinated cross-distro de-facto standard. libexec/ and binaries in libdir are entirely out-ruled by default (binaries in libdir can be an exception) in Debian and SUSE for example. Fedora wants to be different for no understandable reason; in my view, just for the sake of being different.

And right, I call that bad behaviour and an active sabotage of the effort to define a common Linux environment, when this is recommended as a default in Fedora.

I personally have no problem with libexec/, I would not forbid it, but I don't like to be recommended at all. And having subdirectories in libexec/ makes zero sense to me personally, for that we have lib/<pkgname>/ already.

Without having libexec64/ and bin64/, the Fedora rules are just inconsistent and broken in itself, which should be apparent to anybody who really thinks about them.

The GNU Coding standards do not reflect this:

"The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you are using Autoconf, write it as ‘@libexecdir@’.)

That's right, but it is more a placeholder than a directory name. It makes not much sense as a standalone directory with a subdir in it, it provides nothing on top of the currently well-established alternative. That is the reason almost all other distros never allowed it to be used.

The Filesystem Hierarchy Standard does not specify it at all.

They try to for the next revision, because Fedora pushed it in, but thankfully they are not too confused and right away out-rule using both models at the same time, which should make everybody pretty easy to grasp, that we don't need it when he have already the other model in use. And that other model is not a subject to discussion and will stay as it is, as long as these project are actively maintained. It is the de-facto API of these tools which will for sure not be changed because of these non-sensical Fedora guidelines.

Anyway, I'm out of this "discussion". I'm disappointed since the time I opened a similar ticket myself, and have given up arguing against walls here.

I would be very thankful if people can at least stop calling it - what upstream projects and almost all other distros have agreed on for a very long time - a "violation", and stop dreaming that upstream systemd, udev, dracut, udisks, ... will follow that Fedora-only nonsense. For me (and I claim to speak for a bunch of others too) these Fedora-only being-different-for-no-technical-reasons rules are just a "violation" of any common sense.

Consistency with other packages in the distribution and consistency with the distribution's historical practices ''are'' technical reasons.

It may be valid to update the way we're doing things, but we need to work together on that (as Garrett suggests in the issue description way up at the top here). Minimizing Linux balkanization is an admirable goal; doing it by saying "now everyone must do it the way we've chosen" isn't constructive. Please work with the process we have or fix the package to match the standards. https://bugzilla.redhat.com/show_bug.cgi?id=816818

Replying to [comment:3 rdieter]:

One potential constructive path: I'd personally consider allowing /usr/lib/%{name} for items that are intentionally not multilib'd (but something like this has yet be proposed formally).

We now have a guideline that allows /usr/lib for non-multilib. Do we need to do anything to resolve this conflict of opinion now?

• Does FESCo need to explicitly exempt the things that systemd ships in %{_prefix}/lib from multilib? (If I understand correctly, these are all programs so I think that's a no).
• Is there some FPC documentation on systemd that should be updated to use %{_prefix}/lib instead of or in addition to %{_libdir}?

Replying to [comment:10 toshio]:

We now have a guideline that allows /usr/lib for non-multilib. Do we need to do anything to resolve this conflict of opinion now?

• Does FESCo need to explicitly exempt the things that systemd ships in %{_prefix}/lib from multilib? (If I understand correctly, these are all programs so I think that's a no).

It's also the unit files shipped by every package that contains a service, among other things. Will those require an explicit exception?

There are two pieces to systemd that are currently in violation of the guidelines: unit files and helper applications.

• Helper applications could be covered under a non-multilib exception by fesco.
• The unit files are data and would not be covered.

However, if fesco wishes, they could let us know that they would like both pieces of systemd to be granted a specific exception and we will write into the guidelines that systemd unitfiles and helper applications are allowed to install into %{prefix}/lib

We would prefer that fesco does not grant a non-multilib exception alone (ie: allowing systemd to keep the helper applications in %{prefix}/lib but still having to move unitfiles) as that seems like it would be confusing and wouldn't do anything to satisfy the systemd packagers. If we're wrong and the systemd packagers feel splitting where the unitfiles install from where the helper applications install is suitable we wouldn't block that, though.

FESCo granted a special exception for systemd (helpers and unitfiles) so we just need to write that into the guidelines.

We wrote this in a more generic way, closing.