On Thu, 20.12.12 23:24, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> 2) we have to pressure upstream projects to needlessly
complicate their
> code and buildsystem with stuff like $libexecdir variables in their
> autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib
> or something on other distros - which is kind of an imposition on
> upstreams
>
Since neither of these things are required by the packaging guidelines, I
believe the premise of your argument is deeply flawed.
1) As i've said before, there is no packaging guideline requirement that
maintainers restrict helper applications to libexec. Helper apps can go
in either %{_libdir} or %{_libexecdir} (and really, helper apps should be
able to go in %{_prefix}/lib under a simple multilib exemption rather
easily now as well.)
2) the systemd exceptions allows placing files in %{_prefix}/lib rather
than %{_libdir} (the exceptions allow both putting the helper apps in there
which would generally be okay with just a multilib exception and the unit
files which are arch specific data and therefore usually go in %{_libdir}
and therefore needed a special exception). The only reason people can drag
%{_libexecdir} in to this discussion is that helper binaries are allowed in
either %{_libdir} or %{_libexecdir}. In the context of forcing people to
use a specific directory not specified by standards its meaningless because
%{_libdir} is a suitable alternative.
it is simply wrong to place internal binaries in %{_libdir}. internal
binaries should not be subject to multlib'ed dirs, the same way as
binaries in bin/ are not...
3) lennert is not asking that we give permission for packages to use
something other than %{_libexecdir} if upstream doesn't support it. He's
asking us to forbid use of libexecdir within fedora packages no matter what
the package maintainer and upstream support.
Not true. I am saying the guidelines should guide people to do the
right thing, but not be force too much.
Lennart
--
Lennart Poettering - Red Hat, Inc.