Yeah, except it according to FHS is --libexec=/usr/lib/%{name}. (Yes, no lib64 in it).

hmm thats stupid as the code dovecot puts there is definitely arch dependent and i would need to do "--libexec=%{_libdir}/%{name}" instead.

so ... do we strictly follow FHS here or do we make it "%{_libdir}/%{name}"?

do we have any solution for this yet?

atm the macro still passes /usr/libexec 

I'll use %{_libdir}

Fixed in STABLE.

IMHO this is not correct.

dovecot is actually a good example for why %{_prefix}/lib (not %{_libdir}) should be used: It installs only executables, no shared libraries, into that directory so that they can be executed by other executables. 32bit executables can execute 64bit executables and vice versa, so there's no need for having %{_lib} in the path.

In the rare (and wrong) case where a package installs not only executables, but also shared libraries into %{_libexecdir}, it's a bug in that package and should be fixed there instead of making helper executables unshareable for correctly working packages.

See also:

bug 157894 (related)
bug 116589 (another example where %{_prefix}/lib must be used)

dovecot issue reported separately as bug 175418

> hmm thats stupid as the code dovecot puts there is definitely arch dependent
> and i would need to do "--libexec=%{_libdir}/%{name}" instead.

No, this is correct. FHS defines libexecdir as place for binary helpers, not libraries. That is why libexecdir files are not part of -32bit packages: 64 bit helpers can be called directly from 32 bit libraries. So the directory must be equal for both 32 bit and 64 bit packages.

This is the same case as bindir, but this one is not part of the default $PATH - if you will define --bindir=/usr/bin32, you will break your packages.

*** Bug 175418 has been marked as a duplicate of this bug. ***

The redefinition of %_libexecdir to %_libdir is IMHO worse than rpm's default value of /usr/libexec because

(1) During the last months, many packages started using %configure; which in turn uses %_libexecdir;

(2) The redefined value results in many executables directly in %_libdir, which is not was %_libdir was meant for (only exceptional packages like sendmail should install their executables there, but in general, a subdirectory should be used);

(3) Always using a subdirectory (i.e., defining it to %_prefix/lib/%name) would not be much better either, because some packages are already installing their stuff into %_libexecdir/subdir which would result in too many subdirs;

(4) If it were still defined to what it is by default, it were at least possible for packagers to actually see that there's something wrong (e.g. with a brp script that warns about /usr/libexec usage), but the way it currently is, more and more packages are getting wrong libexecdirs (e.g. basically all xfce packages have wrong libexecdirs because it's now easily possible to completely ignore the difference of meaning between $(libexecdir) and $(libdir) according to autoconf/automake standards).

Maybe, but libexecdir was just changed to be consistent to the way it is defined in other distributions. So it's nothing SUSE specific.

Consistent, but incorrect. Only vendors, which provide bi-arch and -32bit library packages are affected by problems caused by --libexecdir=%{_libdir}. The rest will never reach problem "more libraries, one binary".

There is another SuSE level solution: -32 bit packages will include binaries in %{_libdir}, which may be potentially libexecs. I guess it's suboptimal solution.

I don't think that the change of libexecdir makes anything more consistent to the way it is defined in other distributions. Actually I don't have a Fedora installation right now, but in their "rpm.rpm" I can find

./usr/lib/rpm/athlon-linux/macros:%_libexecdir          %{_exec_prefix}/libexec
./usr/lib/rpm/i386-linux/macros:%_libexecdir            %{_exec_prefix}/libexec
./usr/lib/rpm/i486-linux/macros:%_libexecdir            %{_exec_prefix}/libexec
./usr/lib/rpm/i586-linux/macros:%_libexecdir            %{_exec_prefix}/libexec
./usr/lib/rpm/i686-linux/macros:%_libexecdir            %{_exec_prefix}/libexec
./usr/lib/rpm/macros:%_libexecdir               %{_exec_prefix}/libexec
./usr/lib/rpm/macros:   --libexecdir=%{_libexecdir} \\\
./usr/lib/rpm/macros:   libexecdir=%{?buildroot:%{buildroot}}%{_libexecdir} \\\
./usr/lib/rpm/macros:  %{-C:${_mydir}}%{!-C:.}/configure %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} --infodir=%{_infodir} %* ; \
./usr/lib/rpm/noarch-linux/macros:%_libexecdir          %{_exec_prefix}/libexec
./usr/lib/rpm/pentium3-linux/macros:%_libexecdir                %{_exec_prefix}/libexec
./usr/lib/rpm/pentium4-linux/macros:%_libexecdir                %{_exec_prefix}/libexec
./usr/share/doc/rpm-4.4.2/macros:    %_libexecdir       %{_exec_prefix}/libexec

and in their "redhat-rpm-config.rpm" there is

./usr/lib/rpm/redhat/macros:    --libexecdir=%{_libexecdir} \\\
./usr/lib/rpm/redhat/macros:    libexecdir=%{?buildroot:%{buildroot}}%{_libexecdir} \\\
./usr/lib/rpm/redhat/macros.orig:       --libexecdir=%{_libexecdir} \\\
./usr/lib/rpm/redhat/macros.orig:       libexecdir=%{?buildroot:%{buildroot}}%{_libexecdir} \\\

That is, they are really installing things into /usr/libexec. This is their officially approved "FHS exception", see http://fedoraproject.org/wiki/Packaging/Guidelines#head-e1c5548cbbe551c7a43d375c524ab2ea0188557e

I bet that "rpm --eval %_libexecdir" will return "/usr/libexec" on a Fedora system.

What Mandriva does is unknown to me, but usually they are creating new macros for problem cases instead of changing existing ones.

Our definition was taken from mandriva, as the fedora one violates the standard.

Mid-air collision...

Yes, Mandriva actually seems to do the same as SUSE (%_libexecdir==%_libdir), but they have a different biarch concept. They don't have -32bit packages, but are using the complete i586 packages on x86_64 including helper binaries (which is not the case on SUSE; on SUSE, the -32bit packages contain only shared libraries). Therefore they are not affected by the problem that -32bit libraries won't find their helper binaries in lib64 directories on x86_64.

They also have some questionable libexecdir-related patches in their packages.

(In reply to comment #13)
> Our definition was taken from mandriva, as the fedora one violates the
> standard.

I wonder what standard that should be. There is none. Take the findutils package as an example. Right now it uses ./configure, not %configure. Assuming that it would switch to %configure,

(1) %_libexecdir=/usr/libexec would be wrong because of FHS;

(2) %_libexecdir=%_libdir would be wrong because the executable helpers would end up in a library directory;

(3) %_libexecdir=%_prefix/lib/%name would change meaning because %name is "findutils", not "find".

It also switched from /usr/lib/find to /usr/lib64/find on x86_64 between 10.1 and 10.2. Who knows why.

http://lists.opensuse.org/opensuse-commit/2006-08/msg00265.html

IMHO the only sane solution is using something that can be easily autodetected (like /usr/libexec) and forcing packagers to define their own value as there is nothing that works properly for all packages and the current biarch (more exact: nobiarch) concept.

Ad comment 15: (1): agree

(2): partially agree. There is a problem, that there is no strict convention, how to use libexecs. Some packages place libexec binaries to %{_libexecdir}, other packages to %{_libexecdir}/name and other even to %{_libexecdir}/name/epoch

(3): Most libexecs are specific for a single package, so dynamic value does not cause problems (for most packages, but maybe not for all).

Ad comment 16: Yes, if brp check will recommend correct fix, i. e. for:
/usr/libexec/%{name}/name/foo -> --libexecdir=%{_prefix}/lib
/usr/libexec/%{name}/foo -> --libexecdir=%{_prefix}/lib/%{name}
with optional recommendation:
/usr/libexec/%{name}/foo-applet -> --libexecdir=%{_prefix}/lib/gnome-panel
(in case it is a gnome-panel applet)

There is a technical spec file problem, which should be part of this recommendation:
If the file list already contains %{_libdir}/%{name}, then file list must be in the form:
%{_libdir}/%{name}
%if "%{_libdir}" != %{_prefix}/lib"
%{_prefix}/lib/%{name}
%endif

If you will revert to libexec, I can prepare the brp check.

If you will set it to %{_prefix}/lib, I can prepare different check, which will fail on binaries directly in %{_libdir}.

If you will set it to %{_prefix}/lib/%{name}, there is probably no way to check, that "libexec path is too complicated" or "your package needs the same libexecdir as package foo2".

Could this please finally be fixed? There are packages that have binaries with special permissions in %_libexecdir and it sucks having to list everything twice in /etC/permissions

I submitted request 14072 to change it to %{_exec_prefix}/lib for factory

SUSE Linux 10.1 has been out of support for some time, and according to comment 19
S Kulow fixed this for factory back in 2009

Therefor I'm closing this bug as fixed.