Lennart Poettering <mzerqung@xxxxxxxxxxx> writes:
>> > 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.
Having been a 64bit RHEL and Fedora user for years, I couldn't agree
more. And I believe a firm policy is needed for consistency and to avoid
confusion. One concrete example is Nagios plugins. They're helper
binaries and are put in %{_libdir}/nagios/plugins. To keep things
consistent one the same architecture (having all plugins in the same
location to avoid complicating configuration), even noarch plugins are
built as architecture dependent packages. That shouldn't be necessary.
Regards,
--
Trond H. Amundsen <t.h.amundsen@xxxxxxxxxxx>
Center for Information Technology Services, University of Oslo
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
