Recommending %{_libdir}/%{name} will result in /usr/lib64/foo/ which is very broken.
"Application private directories' are for binaries not for libraries and are not architecture dependent; they MUST live in /usr/lib, never in /usr/lib64, regardless of the architecture. It is also defined that way by LSB.
As a side note, not directly related to the bug above:
In general, we recommend, and all new tools use already, the LSB defined /usr/lib/<pkgname>/ dir, because libexec/ is entirely forbidden to use on all other Linux distributions, and we want to share more with them.
There is no need to get rid of libexec in Fedora, it's nothing wrong with it in general; but recommending it in the packaging guidelines seems backwards to me, and against all common sense in upstream Linux development.
It's a pretty useless Fedora'ism that serves no real purpose and is just different from everything else, and not showing respect how Linux in general should look like. We work hard to make the life of 3rd party developers easier across distributions; recommending libexex/ solves not a single problem that isn't already solved since many years in all other distributions.
Both proposals (forcing /usr/lib and abandoning libexecdir) were soundly rejected. (+1:0, 0:0, -1:5).
Fedora's packaging guidelines are structured around the Filesystem Hierarchy Standard, with the notable exception of libexec, which has a long tradition of use in GNU projects. Our reading of the FHS does not require that /usr/lib be used (or forbid /usr/lib64 from being used). In fact, the FHS says "/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are not required."
The FPC can see the interest in /usr/lib, as well as the concern that libexec is not specified in the FHS. It is the hope of the FPC that libexec will be added to the FHS in the next revision of that standard, whenever that may be. (The FPC opened a ticket against the FHS to add libexec several years ago, it is bug #101 against the FHS in bugs.freestandards.org (currently down).)
However, this ticket does not suggest any good alternative, nor is the FPC aware of any good alternative to libexec.
Lastly, the FPC is generally leary of making changes to existing guidelines in the name of "cross distribution compatibility", especially when distributions like Debian and Ubuntu are intentionally incompatible in major ways (e.g. 64bit handling).
This is a serious bug. Please read the start of it and not only the later 'unrelated' section. This is not about 'libexec' in general, this is about the use of $libdir, which is as wrong to recommend as it can be. This is a real bug! We must not install stuff in lib64.
At the meeting we considered the start and end separately and decided to reject both. If you have new arguments, give them when reopening.
What's so hard here?
Recommending %{_libdir}/%{name} is just utterly wrong. It must be %{_prefix}/lib/%{name}. Using /usr/lib64/foo/ for anything that is not *.so makes absolutely no sense at all.
Replying to [comment:4 kay]:
What's so hard here? Recommending %{_libdir}/%{name} is just utterly wrong. It must be %{_prefix}/lib/%{name}. Using /usr/lib64/foo/ for anything that is not *.so makes absolutely no sense at all.
Consider the vte package (which is multilib) and:
vte.i686: /usr/lib/vte/gnome-pty-helper
vte.x86_64: /usr/lib64/vte/gnome-pty-helper
...now in theory both could go into /usr/lib and we could rely on rpms coloring to fix it, but that's never a great fix ... and it can get ugly when you need to split what is in /usr/lib vs. /usr/lib64 (Eg. mono-core or xulrunner). There is no reason to not just use %{_libdir}, and there are no better proposals.
Login to comment on this ticket.