Description of problem: The packaging guideline [1] that relates to libexecdir states that %{_libdir}/%{name} may be used as a fallback in the case of software that does not support the user of libexecdir, such as systemd. Systemd, however, uses /usr/lib/%{name} unconditionally, without regard to architecture. Per the discussion in FPC ticket #158 [2], placing compiled executables in /usr/lib/%{name} for all architectures instead as opposed to using %{_libdir}/%{name} creates a conflict with Fedora's current packaging guidelines that must be resolved. Note that there are multiple ways to fix this bug. Some possible fixes include moving systemd's executables elsewhere, applying for and receiving a guideline exception, and changing the packaging guidelines themselves. The FPC have discussed the latter in the past [3]. [1] http://fedoraproject.org/wiki/Packaging/Guidelines#Libexecdir [2] https://fedorahosted.org/fpc/ticket/158 [3] https://fedorahosted.org/fpc/ticket/139 Version-Release number of selected component (if applicable): systemd-44-7.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. wget http://kojipkgs.fedoraproject.org/packages/systemd/44/7.fc17/x86_64/systemd-44-7.fc17.x86_64.rpm 2. rpm -qpl systemd-44-7.fc17.x86_64.rpm | grep /usr/lib/systemd/systemd Actual results: /usr/lib/systemd/systemd /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-cryptsetup /usr/lib/systemd/systemd-detect-virt /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-logind /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/systemd-readahead-collect /usr/lib/systemd/systemd-readahead-replay /usr/lib/systemd/systemd-remount-api-vfs /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/systemd-timestamp /usr/lib/systemd/systemd-uaccess /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-vconsole-setup Expected results: (none) Additional info: This bug is not intended to be a discussion of the merits of libexecdir and extant packaging standards. The issue is that the current packaging guidelines do not allow the current systemd package's filesystem layout and the FPC chose not to make a general exception for it during their most recent discussions on the issue [2, 3], so the conflict between the systemd package and the packaging guidelines must still be resolved.
I'd say the guideline needs reworking; this is violated by a variety of packages in the distribution (cups, gcc, sendmail, etc.), none of which have a particularly compelling technical reason to change.
(In reply to comment #0) > Description of problem: > The packaging guideline [1] that relates to libexecdir states that > %{_libdir}/%{name} may be used as a fallback in the case of software that does > not support the user of libexecdir, such as systemd. I find the request strange. How am I supposed to call the programs from arch-independent scripts (or, say, refer to them from systemd unit files), if their location depends on the installed arch?
Systemd or udev cannot and will not be changed to follow these rules. The directories are de-facto API and must not be altered by the distribution. As long as there is no /usr/bin64/ and no /usr/libexec64/, the entire idea of installing helper binaries in $libdir is pretty pointless besides a very few valid exceptions. It's not more than a weird idea, that should certainly not end up as a default recommendation in the packaging guidelines. Application-private directories are LSB-defined, and all major distros agreed to use /usr/lib/<pkgname>/, and so should Fedora. Fedora, for some reason though, wants to be special here and tries to define something else, which not only lacks technical reasons, it is actually doing more harm than good at a greater scale. These rules are upstream-ignorant, and boycott our effort to minimize the Linux balcanisation, and the needless differences between the distributions. I'm closing this; systemd, udev and a bunch of other projects will not be changed. Please help fixing the non-sensical Fedora-only rules.
(In reply to comment #3) > I'm closing this; systemd, udev and a bunch of other projects will not be > changed. Please help fixing the non-sensical Fedora-only rules. I *am* trying to help fix Fedora's rules. The purpose of this bug is to resolve the conflict between systemd and Fedora's rules, not to simply dictate where systemd's files go on the filesystem. As I mentioned in the bug description, fixing Fedora's rules is a perfectly valid (and probably friendlier) way to fix this issue, so please do not assume that this bug is simply asking you to move files to a place that doesn't make sense to you.
So, proposal: 1. Packages may use /usr/lib/<foo> as an alternative for /usr/libexec/<foo> for binaries executed by the package or as an adjunct to the package. Packages may not use /usr/lib/<foo> for shared objects unless that is the architecturally-correct directory. 2. An exception is granted to the following packages that predate UsrMove for using /usr/lib/<foo> as an alternative to /usr/share/<foo> for architecture-independent configuration: - udev - systemd
(In reply to comment #3) > Systemd or udev cannot and will not be changed to follow these rules. The > directories are de-facto API and Note that in that case they probably violate the FHS: http://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibLibrariesForProgrammingAndPa "internal binaries that are not intended to be executed directly by users or shell scripts.". If something is an ABI, it is not internal. (This sentence is there for both /usr/lib and /usr/libexec, and by reference for /usr/lib64 , so in a sense it doesn't matter - but as long as we are trying to figure out the best way to arrange things, it is relevant.) > must not be altered by the distribution. I'm sorry, that's backwards. The distribution defines standards for packaging upstream software, upstream software does not define standards for distributions. (Otherwise there would be no way to achieve any consistency.)
(In reply to comment #5) > So, proposal: > > 1. Packages may use /usr/lib/<foo> as an alternative for /usr/libexec/<foo> for > binaries executed by the package or as an adjunct to the package. We should probably mention, that LSB does not allow both to be used at the same time. The current LSB does not allow libexec/ at all, which is why only Fedora uses it, and the future LSB will probably allow it now that Fedora submitted it, but they explicitly do not allow both directories to be used by the same package. > 2. An exception is granted to the following packages that predate UsrMove for > using /usr/lib/<foo> as an alternative to /usr/share/<foo> for > architecture-independent configuration: We will very likely continue to use /usr/lib/<foo>/, even in new projects. Things that we consider primarily 'private', we usually install in the same directory. Executables convert from scripts to compiled binaries or the other way around, and we do not want to move them. Packages should be free not to split out architecture-dependent from independent tools. Most to that today, and that should work the same way tomorrow. I don't think we should list exceptions here.
(In reply to comment #6) > > Systemd or udev cannot and will not be changed to follow these rules. The > > directories are de-facto API and > > Note that in that case they probably violate the FHS: > > http://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibLibrariesForProgrammingAndPa > > "internal binaries that are not intended to be executed directly by users or > shell scripts.". If something is an ABI, it is not internal. The tools of the Base OS are not a big blob. The udev and systemd binaries are surely called by other Base OS tools, even when they are not public API in the sense of /usr/bin/, and they are surely never executed by "users" like the above sentence mentions. It's a kind of contract between Base OS tools, not for the platform as a whole. It's done that way since long, and works well, and there is no reason to change that. > (This sentence is there for both /usr/lib and /usr/libexec, and by reference > for /usr/lib64 , so in a sense it doesn't matter - but as long as we are > trying to figure out the best way to arrange things, it is relevant.) > > > must not be altered by the distribution. > I'm sorry, that's backwards. The distribution defines standards for packaging > upstream software, upstream software does not define standards for > distributions. (Otherwise there would be no way to achieve any consistency.) It is not. The same way we define a de-facto API between Base OS tools, we define the Base OS itself. And unless there are technical reasons, distributions are not expected to needlessly change them for the sake of consistency of the Linux platform. And if there are technical reasons, we will change the upstream tools. In case people haven't noticed how broken this "discussion" is: Not a single other distribution besides Fedora has a problem with this. They usually even have much higher standards than Fedora regarding the packaging, and dictate exactly all of that what Fedora calls a "violation" in their own packaging guidelines. And to make it perfect, almost all the (ignorant) developers working on these (violating) tools in question here, are Fedora developers. This should give a hint what is broken here, and the guidelines should be fixed, or aligned with LSB, or whatever, ... instead continuing to run in circles, wasting all our time, making up needless Fedora-only rules for absolutely zero technical benefit.
I am pretty strongly of the opinion that libexec should just go away. Only Fedora knows libexec, and I fail to see why. Patching all software to support this dir even if upstream explicitly doesn't support it (and is in full compliance with LSB in doing so) is just a waste of time, for little use. I think we should work against the debalkanization of Linux as good as we can. Sometimes that means others have to adopt our standards, but in this case I think it's Fedora who should follow the scheme everybody else uses. I think the fedora packaging guidelines should recommend usage of a private dir in /usr/lib as place for private binaries, but (to make the transition easy) maybe allow /usr/libexec for them too. But really, the focus should be on /usr/lib for this, not /usr/libexec.
IMHO, non-multilib stuff has no business being in /usr/lib. It needs to go to /usr/libexec if it's executable, /usr/share otherwise (with architecture-independent scripts being allowed in both). Gratuitous multilibbing should also be discouraged. A package should only be allowed to install to lib64 if at least some of the files are multilib (and ideally those files should be separated out, but if that is not supported, multilibbing the whole directory is acceptable as a last resort). The problem with doing things the systemd way is that you end up with /usr/lib containing a mix of 32-bit multilibs and native 64-bit stuff on 64-bit system, a big mess.
Here's a status update: A FPC discussion about this topic [1] is underway. It began due to recent revision proposals for the java guidelines, but I encourage people with other, useful use cases to constructively contribute to that thread. In today's meeting, FESCo agreed [2] to review the situation after that FPC discussion ends. [1] http://lists.fedoraproject.org/pipermail/packaging/2012-November/008757.html [2] https://fedorahosted.org/fesco/ticket/969#comment:2
(In reply to comment #10) > The problem with doing things the systemd way is that you end up with > /usr/lib containing a mix of 32-bit multilibs and native 64-bit stuff on > 64-bit system, a big mess. Sure, a "big mess" like /usr/bin. And now?
Seems the FPC ticket is closed, we can close this one now too I guess.