#969 libexecdir guideline conflicts with extant packages
Closed None Opened 6 years ago by gholms.

= phenomenon =
The packaging guideline that relates to libexecdir does not allow packages to unconditionally put executables in /usr/lib without regard to architecture, but Fedora contains several packages -- some old, some new -- that already do this. We seem to be at an impasse; can FESCo resolve this somehow?

= background analysis =

The packaging guideline that relates to libexecdir encourages packagers to use %_libexecdir/%name where possible, and %_libdir/%name as a fallback when upstream does not support it. Several existing packages, however, use /usr/lib regardless of architecture, in violation of this rule. The FPC's stance with regards to this issue has been very consistent over time [1, 2], but there seems to be enough resistance to this [3, 4] that I believe we should re-visit this issue so we can resolve the difference between the rules and reality.

The most memorable example of this, systemd, ended up with executables in /usr/lib after the !UsrMove feature moved files that used to live in /lib due to the lack of /libexecdir, to there. The position that that package's maintainers take on this issue is that Fedora stands alone among distros with its support of libexecdir, and that that should change for the benefit of the greater community. The FPC's position is that of consistency among Fedora's packages and with the distribution's history.

That argument is as old as Fedora itself, of course. I don't intend to rehash it or argue for a specific viewpoint; all I am looking to do is resolve the disconnect between extant packages and the packaging guidelines.

FPC's last vote ![2] ended up being one between /usr/lib/%name being an acceptable alternative to %_libexecdir/%name, and fixing systemd to comply with the current rules. They decided upon the latter and asked me to file a bug against systemd that asks for it to be fixed, and in the event it is not, file a FESCo ticket, hence this ticket.

= implementation recommendation =

I have seen four possible resolutions for this disconnect:

  1. Allow /usr/lib/%name for items that are intentionally not multilib.
  2. Allow /usr/lib/%name as an additional fallback for %_libexecdir when upstream does not support it.
  3. Allow specific exceptions for certain packages.
  4. Fix all of the conflicting packages.

What do you folks think?

= references =

![1] https://fedorahosted.org/fpc/ticket/139 [[BR]]
![2] https://fedorahosted.org/fpc/ticket/158 [[BR]]
![3] https://fedorahosted.org/fpc/ticket/158#comment:2 [[BR]]
![4] https://bugzilla.redhat.com/show_bug.cgi?id=816818#c3

https://fedorahosted.org/fpc/ticket/158#comment:6 sums the situation up

FESCo agreed to review the situation again after Java exception is solved (+9,-0)

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).

Given the FPC decided on following wording:
"If a package has been granted an explicit exception from FESCo to permit it to not be multilib enabled, then it may use %{_prefix}/lib instead of %{_libdir}."

I am adding this ticket for meeting.

Thanks for reminding me -- I've reopened the FPC ticket as well:


Discussed in today's FPC meeting. Where to go from here is in: https://fedorahosted.org/fpc/ticket/158#comment:12

FESCO on today's meeting agreed upon the following exceptions:

  1. systemd is granted an exception to put helper applications in /usr/lib/systemd

  2. the systemd unit files of all the packages are granted an exception to be under /usr/lib/systemd

Login to comment on this ticket.