[devel] Q: mrtg под x86_64

[Andrei Bulava]

Sergey Vlasov wrote:
> On Tue, Feb 14, 2006 at 10:53:21AM +0200, Andrei Bulava wrote:
> 
>>QA Team Robot wrote:
>>
>>>	13 NEW unmet dependencies detected:
>>
>>>mrtg#2.13.2-alt1        	/usr/lib64/libgd.so.2()(64bit)
>>>mrtg#2.13.2-alt1        	/usr/lib64/libpng12.so.0()(64bit)
>>
>>А как именно это понимать? Ведь если unmet dependencies порождаются
>>_после_ того, как mrtg собрался под x86_64, то проблемы где-то намного
>>глубже?
> 
> 
> Не надо делать %define _libdir /usr/lib - rpm-4.0.4-alt59 использует
> %_libdir для определения списка стандартных путей к библиотекам, а все
> *.so, расположенные в другом месте, попадают в зависимости с полными
> путями.  Переопределение %_libdir ломает этот механизм и приводит к
> появлению таких неверных зависимостей.

Спасибо, я понял. "Факир был пьян, и фокус не удался" (c) не мой.

> Если там действительно noarch, надо класть его в %_datadir (но если в этих
> каталогах могут появляться arch-куски, добавляемые другими пакетами,
> придётся оставить их в %_libdir).

Увы и ах, это перловая каша, по несчастью приправленная единственным
ELF'ом %_bindir/rateup, из-за которого пакет становится arch-зависимым :-(

Пропатчить mrtg на использование %_datadir - не вопрос (понятно, что мне
уж очень не хотелось этого делать, хоть и знал, как). А вот для
arch-кусков не приходит в голову другое, чем использовать %_libexecdir,
переопределённый в спеке как /usr/libexec.

Про удобства того, что %_libdir разрешается в /usr/lib для
noarch-пакетов под x86_64, остаётся только мечтать :-\

В сухом остатке имеем необходимость маргинальной сборки mrtg ради работы
под x86_64...

-- 
// AB1002-UANIC