[devel] Q: mrtg под x86_64 (Was: Re: [Sisyphus-cybertalk] I: Sisyphus-20060214 x86_64 unmets: +13 -15 (974/248))

[devel] Q: mrtg под x86_64 (Was: Re: [Sisyphus-cybertalk] I: Sisyphus-20060214 x86_64 unmets: +13 -15 (974/248))

[Andrei Bulava]

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, то проблемы где-то намного
глубже?

IMHO, без /usr/lib64/libpng12.so.0()(64bit) немного приложений будет
устанавливаться под x86_64 :-\

> mrtg#2.13.2-alt1        	perl(RRDs.pm)

> 	15 unmet dependencies have been RESOLVED:

> mrtg#2.12.2-alt1        	perl(RRDs.pm)

Тоже, кстати интересно - как именно технически возникают (и исчезают)
такие "автоматически разрешающиеся неразрешимости" :-)

Вообще, есть доля юмора в моей ситуации: нет ни сборочной, ни тестовой
машинки под x86_64, зато есть сервер под ALM 2.4, и руководство
подзуживает "почему не 64-битный Linux?" :-(

-- 
// AB1002-UANIC

Re: [devel] Q: mrtg под x86_64 (Was: Re: [Sisyphus-cybertalk] I: Sisyphus-20060214 x86_64 unmets: +13 -15 (974/248))

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

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 ломает этот механизм и приводит к
появлению таких неверных зависимостей.

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

> > mrtg#2.13.2-alt1        	perl(RRDs.pm)
> 
> > 	15 unmet dependencies have been RESOLVED:
> 
> > mrtg#2.12.2-alt1        	perl(RRDs.pm)
> 
> Тоже, кстати интересно - как именно технически возникают (и исчезают)
> такие "автоматически разрешающиеся неразрешимости" :-)

Просто пакет rrd по каким-то причинам не собран для x86_64, а автопоиск
зависимостей для perl сумел разобрать скрипты и найти зависимость без
загрузки этого модуля.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [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

[devel] Re: Q: mrtg под x86_64

[Michael Shigorin]

On Tue, Feb 14, 2006 at 01:17:03PM +0200, Andrei Bulava wrote:
> Увы и ах, это перловая каша, по несчастью приправленная
> единственным ELF'ом %_bindir/rateup, из-за которого пакет
> становится arch-зависимым :-( Пропатчить mrtg на использование
> %_datadir - не вопрос (понятно, что мне уж очень не хотелось
> этого делать, хоть и знал, как).

Симлинковать каталог не проще?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: mrtg под x86_64

[Andrei Bulava]

Michael Shigorin wrote:
> On Tue, Feb 14, 2006 at 01:17:03PM +0200, Andrei Bulava wrote:
> 
>>Увы и ах, это перловая каша, по несчастью приправленная
>>единственным ELF'ом %_bindir/rateup, из-за которого пакет
>>становится arch-зависимым :-( Пропатчить mrtg на использование
>>%_datadir - не вопрос (понятно, что мне уж очень не хотелось
>>этого делать, хоть и знал, как).
> 
> 
> Симлинковать каталог не проще?

Не задумывался. Как именно предлагаешь? (не соображу без подсказки -
голова забита под завязку OpenLDAP'ами и shared address book'ами).

-- 
// AB1002-UANIC

Re: [devel] Q: mrtg под x86_64

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

On Tue, Feb 14, 2006 at 01:17:03PM +0200, Andrei Bulava wrote:
> Пропатчить mrtg на использование %_datadir - не вопрос (понятно, что мне
> уж очень не хотелось этого делать, хоть и знал, как). А вот для
> arch-кусков не приходит в голову другое, чем использовать %_libexecdir,
> переопределённый в спеке как /usr/libexec.

А зачем было переопределять %_libexecdir?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Q: mrtg под x86_64

[Michael Shigorin]

On Tue, Feb 14, 2006 at 03:19:48PM +0200, Andrei Bulava wrote:
> >>Увы и ах, это перловая каша, по несчастью приправленная
> >>единственным ELF'ом %_bindir/rateup, из-за которого пакет
> >>становится arch-зависимым :-( Пропатчить mrtg на
> >>использование %_datadir - не вопрос (понятно, что мне уж
> >>очень не хотелось этого делать, хоть и знал, как).
> > Симлинковать каталог не проще?
> Не задумывался. Как именно предлагаешь?

Подумал %_libdir/%name сделать симлинком на %_datadir/%name,
хотя подумал ещё и мож %_datadir/%name/rateup сделать симлинком
туда или чуточку пропатчить mrtg именно про него?

Или попатчить сам скрипт mrtg (глядя в 2.10).

> (не соображу без подсказки - голова забита под завязку
> OpenLDAP'ами и shared address book'ами).

(о, ещё один :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: mrtg под x86_64

[Andrei Bulava]

Dmitry V. Levin wrote:
> On Tue, Feb 14, 2006 at 01:17:03PM +0200, Andrei Bulava wrote:
> 
>>Пропатчить mrtg на использование %_datadir - не вопрос (понятно, что мне
>>уж очень не хотелось этого делать, хоть и знал, как). А вот для
>>arch-кусков не приходит в голову другое, чем использовать %_libexecdir,
>>переопределённый в спеке как /usr/libexec.
> 
> 
> А зачем было переопределять %_libexecdir?

"Было переопределять %_libexecdir" по отношению к mrtg говорить рано. В
mrtg-2.13.2-alt1 мною был (неудачно) переопределён %_libdir. А хак с
"%define _libexecdir /usr/libexec" - в jabberd2 (который, кстати, я тоже
просил заинтересованных проверить под x86_64 на работоспособность.)

На вопрос "зачем надо будет переопределять %_libexecdir в mrtg?" - ответ
очевиден. Я предполагаю, что с таким переопределением пакет будет
выглядеть одинаково на x86 и x86_64 независимо от неопределённой (для
меня, в виду отсутствия доступа к Sisyphus x86_64) ситуации с %_libexecdir.

На данный момент есть такая сущность, как
/usr/lib/mrtg2/helpers/{cpuinfo,iptables-accounting}.pl, упоминаемая в
упакованных конфигурационных файлах, и возможное "плавание" этой
сущности в /usr/lib64 меня не устраивает.

Пока что (rpm-4.0.4-alt59) на x86 я вижу "%define _libexecdir /usr/lib"
вместо ожидаемого архитектурно-независимого "%define _libexecdir
/usr/libexec".

P.S. Прошу прощения за сумбурность и многословность.

-- 
// AB1002-UANIC

Re: [devel] Q: mrtg под x86_64

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Tue, Feb 14, 2006 at 06:46:28PM +0200, Andrei Bulava wrote:
> Пока что (rpm-4.0.4-alt59) на x86 я вижу "%define _libexecdir /usr/lib"
> вместо ожидаемого архитектурно-независимого "%define _libexecdir
> /usr/libexec".

%_libexecdir не является архитектурно-независимым, для этого существует
%_datadir.  %_libexecdir является multilib-независимым, поэтому он
одинаковый на всех архитектурах (сейчас он /usr/lib вне зависимости от
%_libdir).  Короче говоря, вы можете спокойно использовать
%_libexecdir для размещения executables.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: mrtg под x86_64

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

* Dmitry V. Levin <ldv@> [060214 21:59]:
> %_libexecdir не является архитектурно-независимым, для этого существует
> %_datadir.  %_libexecdir является multilib-независимым, поэтому он
> одинаковый на всех архитектурах (сейчас он /usr/lib вне зависимости от
> %_libdir).  Короче говоря, вы можете спокойно использовать
> %_libexecdir для размещения executables.
Как насчёт hasher и gcc?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: mrtg под x86_64

[Andrei Bulava]

Dmitry V. Levin wrote:
> On Tue, Feb 14, 2006 at 06:46:28PM +0200, Andrei Bulava wrote:
> 
>>Пока что (rpm-4.0.4-alt59) на x86 я вижу "%define _libexecdir /usr/lib"
>>вместо ожидаемого архитектурно-независимого "%define _libexecdir
>>/usr/libexec".
> 
> 
> %_libexecdir не является архитектурно-независимым, для этого существует
> %_datadir.  %_libexecdir является multilib-независимым, поэтому он
> одинаковый на всех архитектурах (сейчас он /usr/lib вне зависимости от
> %_libdir).

Да, я криво выразился, имея ввиду то же самое - "%_libexecdir является
multilib-независимым". Спасибо за разъяснение, что он одинаков на всех
архитектурах.

> Короче говоря, вы можете спокойно использовать
> %_libexecdir для размещения executables.

У меня проблема несколько более другого рода, и %_libexecdir для
размещения executables - только часть решения.

Насколько законно будет разместить перловые модули в %_libexecdir/mrtg2?
В таком случае, пока %_libexecdir разрешается в /usr/lib (а это можно
обеспечивать сколь угодно долго для отдельно взятого пакета), не
придётся править исходные коды mrtg - всё ограничится правкой
Makefile.in, что (для меня) всяко приятнее, чем правка исходных кодов.

-- 
// AB1002-UANIC

Re: [devel] Q: mrtg под x86_64

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Wed, Feb 15, 2006 at 09:41:07AM +0200, Andrei Bulava wrote:
> У меня проблема несколько более другого рода, и %_libexecdir для
> размещения executables - только часть решения.
> 
> Насколько законно будет разместить перловые модули в %_libexecdir/mrtg2?

Для перловых модулей, кажется, есть своё отдельное место, отличное от
/usr/lib/mrtg2.

> В таком случае, пока %_libexecdir разрешается в /usr/lib (а это можно
> обеспечивать сколь угодно долго для отдельно взятого пакета), не
> придётся править исходные коды mrtg - всё ограничится правкой
> Makefile.in, что (для меня) всяко приятнее, чем правка исходных кодов.

Если вам нужно получить именно /usr/lib, то так пишите: /usr/lib, не надо
злоупотреблять макросами.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: mrtg под x86_64

[Andrei Bulava]

Dmitry V. Levin wrote:

> Если вам нужно получить именно /usr/lib, то так пишите: /usr/lib, не надо
> злоупотреблять макросами.

Хорошо, я попробую.

-- 
// AB1002-UANIC