Summary/Minutes for today's FESCo meeting (2012-12-19)

[Lennart Poettering]

On Fri, 21.12.12 05:06, Matthew Garrett (mjg59 at srcf.ucam.org) 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.