Bug 816818 - GUIDELINES: Unconditional use of /usr/lib/systemd for compiled executables violates Fedora packaging guidelines
Summary: GUIDELINES: Unconditional use of /usr/lib/systemd for compiled executables vi...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-27 05:40 UTC by Garrett Holmstrom
Modified: 2013-01-11 13:32 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-11 13:32:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Garrett Holmstrom 2012-04-27 05:40:19 UTC
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.

Comment 1 Bill Nottingham 2012-04-27 15:21:53 UTC
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.

Comment 2 Michal Schmidt 2012-04-27 16:05:50 UTC
(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?

Comment 3 Kay Sievers 2012-04-29 21:44:16 UTC
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.

Comment 4 Garrett Holmstrom 2012-04-30 17:05:10 UTC
(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.

Comment 5 Bill Nottingham 2012-04-30 17:31:23 UTC
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

Comment 6 Miloslav Trmač 2012-04-30 17:43:23 UTC
(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.)

Comment 7 Kay Sievers 2012-04-30 19:35:57 UTC
(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.

Comment 8 Kay Sievers 2012-04-30 19:55:32 UTC
(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.

Comment 9 Lennart Poettering 2012-05-02 19:38:27 UTC
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.

Comment 10 Kevin Kofler 2012-11-15 04:40:17 UTC
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.

Comment 11 Garrett Holmstrom 2012-11-15 06:47:24 UTC
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

Comment 12 Kay Sievers 2012-11-15 11:29:05 UTC
(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?

Comment 13 Lennart Poettering 2013-01-11 13:32:05 UTC
Seems the FPC ticket is closed, we can close this one now too I guess.


Note You need to log in before you can comment on or make changes to this bug.