On Fri, 21.12.12 05:06, Matthew Garrett (mjg59@xxxxxxxxxxxxx) wrote:
> On Thu, Dec 20, 2012 at 08:57:58PM -0700, Kevin Fenzi wrote:
> > IMHO, libexecdir is not part of this at all... we already have:
> >
> > "If upstream's build scripts support the use of %{_libexecdir} then
> > that is the most appropriate place to configure it (eg. passing
> > --libexecdir=%{libexecdir}/%{name} to autotools configure). If
> > upstream's build scripts do not support that, %{_libdir}/%{name} is a
> > valid second choice. "
> >
> > It's all about the choice of lib instead of %{_libdir}.
>
> The problem is that in the absence of libexec, there's no consistent
> location to put helper binaries. %{_libdir}/%{name} doesn't work -
> depending on distribution and architecture, your files are now either in
> lib/name, lib32/name or lib64/name. Far from ideal. Lennart's position
> that fundamental system infrastructure belongs in lib makes sense, since
> there's absolutely no good reason for multilibing those components.
Yes, absolutely. That's key here: multilibbing things should be the
exception, and used where strictly *necessary*, not the default for all
files. That means that libraries should go to %{_libdir} since they need
to be available for both 32bit and 64bit. However, non-library stuff
such as internal binaries, or anything else arch specific should not be
in %{_libdir}, but in lib/.
Multilib is not pretty, it's primarily just a hack to fix one specific
problem, and one shouldn't let this specific spill in an otherwise fine
design. Hence: use multilib if you must for a specific file, but only
then.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
