On Thu, 20.12.12 23:24, Toshio Kuratomi (a.badger@xxxxxxxxx) 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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
