Всякие glib2 тоже в /usr/lib держат, и ничо. Лишь бы был штатный способ получить этот путь (обычно это pkg-config).

Это ещё бывает нужно, кто есть разные реализации одного интерфейса, причём, если бывает необходимо держать их установленными в системе одновременно. Типичный и уже хорошо отработанный пример в ALT - MPI.

В случае с HDF5 условия те же, и я не стал изобретать новый велосипед.

pkg-config сейчас сделаю (т.е. уже сделал, да сборочница что-то пока шалит).

(В ответ на комментарий №1)
> Всякие glib2 тоже в /usr/lib держат, и ничо. Лишь бы был штатный способ
> получить этот путь (обычно это pkg-config).
glib2 по крайней мере делает это в libdir, который не везде /usr/lib, а кое-где очень даже /usr/lib64 ;)

По аналогии с различными mpi, я ложу всё в %_libexecdir, а не %_libdir.

Какие могут быть поводы, чтобы первое поменять на второе?

Кстати, 1.8.3-alt4 ушёл в сизиф. Вопрос можно считать решённым или всё же разберёмся с этими %_libexecdir/%_libdir?

Ну, вроде если всё нормально, закрою эту ошибку (переоткрыть никогда не поздно ;) ).

Для разных реализаций можно создать разные подкаталоги в /usr/include.
Мне очень странно видеть библиотеки в /usr/lib на 64-битной системе.
Нельзя ли всё же расформировать этот свой мир в /usr/lib/hdf5-seq/ на стандартные места?
Кстати, зачем вообще несколько реализаций и тем более одновременно установленных?

Ну, закрывая сразу (ибо несерьёно) тему с /usr/include, в свою очередь вхожу в состояние удилевния вопросом?

Откуда он? Почему начали с меня, на не с openmpi? В чём мотивация вопроса? Какие таки стандартные места могут быть у библиотек, которые используются разными людьми и по определению должны лежать в в разных местах? Менять им soname, обзывать библиотеки и сами по-другому - Вы считаете это умнее?

PS, Или. несмотря на крещенские морозы под 40, я воспринял, что это очередной рождественский прикол?

(В ответ на комментарий №7)
> Ну, закрывая сразу (ибо несерьёно) тему с /usr/include, в свою очередь вхожу в
Ну ничего несерьёзного не вижу, заголовочные файлы должны быть в include.

> Откуда он? Почему начали с меня, на не с openmpi? В чём мотивация вопроса?
У меня - потому что я собирал раньше libhdf5, и сейчас собираю с ним программы и библиотеки. Понятия не имею об openmpi.

> Какие таки стандартные места могут быть у библиотек, которые используются
> разными людьми и по определению должны лежать в в разных местах? Менять им
> soname, обзывать библиотеки и сами по-другому - Вы считаете это умнее?
Я, возможно, пропустил причины, по котором пришлось так поступить с libhdf5. 
Но если получаются разные библиотеки, их логично назвать по-разному. Возможно, в этом надо помочь апстриму. Qt, например, не стеснялось называть libqt-mt многопоточную версию библиотеки.

И хотелось бы узнать, зачем необходимо держать в системе одновременно обе версии библиотеки.

"(В ответ на комментарий №7)
> Ну, закрывая сразу (ибо несерьёно) тему с /usr/include, в свою очередь вхожу в
Ну ничего несерьёзного не вижу, заголовочные файлы должны быть в include."

Но они там часто не лежат. Примеры уже были -Qt3 и Qt4.


"> Откуда он? Почему начали с меня, на не с openmpi? В чём мотивация вопроса?
У меня - потому что я собирал раньше libhdf5, и сейчас собираю с ним программы
и библиотеки. Понятия не имею об openmpi."

А я как раз и брал пример с openmpi (на самом деле, у нас несклько разныз библиотек для работы с MPI), разбивая libhdf5 на 2 разных пакета. Если нужна _одна_ библиотека, но собранная _разным_ образом, где её держать? Одни говорять, что в %_libdir/%name. Другие говорят, что в %_libexecdir/%name. Как я понял, правды не знает никто, но я посмотрел, как упакованы библиотеки MPI и сделал так же. И в чём теперь я неправ?


"Я, возможно, пропустил причины, по котором пришлось так поступить с libhdf5. 
Но если получаются разные библиотеки, их логично назвать по-разному."

Видимо, действительно пропустили, ибо это была одна из главных причин, почему я взялся собирать этот пакет. Мне нужна (и нужна до сих пор) библиотека с поддержкой MPI. С другой стороны, большинству остальных пользователей такая поддержка не нужна, и заставлять их ставить себе кучу ненужных пакетов я посчитал менее удачной идеей, чем собрать нужную версию отдельно. И мне ещё важдно было сохранить ряд других пакетов, которые бы и знать не знали, какую именно библиотеку исчпользуют, и им было бы всё равно. 

"И хотелось бы узнать, зачем необходимо держать в системе одновременно обе
версии библиотеки."

Отвечу на любые другие могущие возникнуть вопросы.

"И хотелось бы узнать, зачем необходимо держать в системе одновременно обе
версии библиотеки."

Есть софт, которому нужна именно конкретная версия библиотеки. Например, моему кластерному комплексу совершенно не нужна libhdf5 без поддержки mpi. С другой стороны, есть софт, который собран _именно_ с последовательной версией. Без одновременной установки обеих версий библиотеки в такой ситуации не обойдёшься.

(В ответ на комментарий №9)
> Ну ничего несерьёзного не вижу, заголовочные файлы должны быть в include."
> Но они там часто не лежат. Примеры уже были -Qt3 и Qt4.
Это беспорядок.
 
> А я как раз и брал пример с openmpi (на самом деле, у нас несклько разныз
> библиотек для работы с MPI), разбивая libhdf5 на 2 разных пакета. Если нужна
> _одна_ библиотека, но собранная _разным_ образом, где её держать? Одни
> говорять, что в %_libdir/%name. Другие говорят, что в %_libexecdir/%name. Как 
Архитектурно-зависимые файлы должны быть в %_libdir, а использование %_libexecdir вызывает только недоразумения, на мой взгляд.

> Есть софт, которому нужна именно конкретная версия библиотеки. Например, моему
> кластерному комплексу совершенно не нужна libhdf5 без поддержки mpi. С другой
> стороны, есть софт, который собран _именно_ с последовательной версией. Без
> одновременной установки обеих версий библиотеки в такой ситуации не обойдёшься
? Я что-то не заметил, как альтернативы в /usr/lib совместимы с одновременным использованием библиотек.

Не вижу намека на rpath здесь:
$ pkg-config --libs hdf5
-lhdf5hl_fortran -lhdf5_hl_cpp -lhdf5_hl -lhdf_fortran -lhdf_cpp -lhdf -lgfortran -lstdc++ -lz

А это, видимо, лишнее:
-lgfortran -lstdc++ -lz

"Архитектурно-зависимые файлы должны быть в %_libdir, а использование
%_libexecdir вызывает только недоразумения, на мой взгляд."

Я не нашёл в своё время, где бы это было документально зафиксировано, поэтому и сделал так, как уже делали до меня.

"Не вижу намека на rpath здесь:
$ pkg-config --libs hdf5"

А там его по сути и не должно быть, если есть желание, чтобы софт работал с любой из версий библиотеки. Мы с mike@ так в своё время и порешали (сейчас уже не вспомню, что это был за софт, но он работает и у него с seq-версией nethdf5, и у меня с mpi-версией), что по умолчанию такое поведение предпочтительно. Если же нужна конкретная версия, то софт при сборке делает это самостоятельно, что видно на следующих примерах:

http://git.altlinux.org/people/real/packages/libnetcdf.git?p=libnetcdf.git;a=blob;f=libnetcdf.spec;h=579e2296bb0266570c200787ce6f0d5398b9cb0a;hb=master

http://git.altlinux.org/people/real/packages/libnetcdf.git?p=libnetcdf.git;a=blob;f=libnetcdf.spec;h=c87779ca5361ec3dca76052131f6fcea457638a4;hb=mpi

И у первого из примеров всё как надо выставляется:

> rpm -qR libnetcdf6-seq
alternatives  
libhdf5-6-seq  
/etc/alternatives/packages.d  
/lib/ld-linux.so.2  
/usr/lib/hdf5-seq/lib/libhdf5.so.6  
libc.so.6(GLIBC_2.0)  
libc.so.6(GLIBC_2.1)  
libc.so.6(GLIBC_2.1.3)  
libc.so.6(GLIBC_2.2)  
libc.so.6(GLIBC_2.2.5)  
libc.so.6(GLIBC_2.3)  
libc.so.6(GLIBC_2.3.4)  
libc.so.6(GLIBC_2.4)  
libc.so.6(GLIBC_2.7)  
libhdf5.so.6  
libhdf5_hl.so.6  
libm.so.6(GLIBC_2.0)  
libm.so.6(GLIBC_2.1)  
rtld(GNU_HASH)  
rpmlib(PayloadIsLzma)

"А это, видимо, лишнее:
-lgfortran -lstdc++ -lz"

Были проблемы с undefined symbols, видимо. Я сейчас точно не смогу вспомнить. Но можно поэкспериментировать, конечно, если это имеет какой-то срочный и сакральный смысл.

(В ответ на комментарий №12)
> А там его по сути и не должно быть, если есть желание, чтобы софт работал с
> любой из версий библиотеки. Мы с mike@ так в своё время и порешали (сейчас уже
> не вспомню, что это был за софт, но он работает и у него с seq-версией nethdf5,
> и у меня с mpi-версией), что по умолчанию такое поведение предпочтительно. 

Тем более не вижу необходимости держать в системе две версии библиотеки, из которых может работать только одна, выбранная через альтернативы. Проще было бы пакет переставить с mpi на seq и наоборот.
Зачем добиваться устанавливаемости двух библиотек, если работать можно только с одной?

> Были проблемы с undefined symbols, видимо. Я сейчас точно не смогу вспомнить.
> Но можно поэкспериментировать, конечно, если это имеет какой-то срочный и
> сакральный смысл.
Не имеет.

"Тем более не вижу необходимости держать в системе две версии библиотеки, из
которых может работать только одна, выбранная через альтернативы. Проще было бы
пакет переставить с mpi на seq и наоборот.
Зачем добиваться устанавливаемости двух библиотек, если работать можно только с
одной?"

Наверно, я несколько неадекватно выражаюсь, что меня неадекватно понимают. Работать могут обе версии библиотеки. Если нет конкретных предпочтений, клиент просто пользуется через alternatives, иначе задействуется RPATH. Этот вариант мне представляется более предпочтительным, чем  перестановка пакетов туда-сюда, тем более мне как раз mike@ жаловался, что зачем ему OpenMPI, когда он не используется, но ставится силком (наш apt-get работает так, что считает libhdf5 менее приоритетным для установки, чем libhdf5-mpi, отчего и изначальную библиотеку пришлось переименовывать). А мне вот нужна была и софтинка от mike@, и весь комплект, завязанный на OpenMPI, и что бы мне пришлось делать? Через каждые несколько минут удалять то одну вязанку пакетов, то другую? Я и воспользовался решением, которое родилось в голове, тем более никто ничего другого предложить не смог.

PreScriptum: давайте спросим знатоков, вдруг кто найдёт время и объяснение.

(In reply to comment #12)
> > Архитектурно-зависимые файлы должны быть в %_libdir, а использование
> > %_libexecdir вызывает только недоразумения, на мой взгляд.
> Я не нашёл в своё время, где бы это было документально зафиксировано,
> поэтому и сделал так, как уже делали до меня.

Цитирую Filesystem Hierarchy Standard (/usr/share/doc/fhs-2.3/fhs.txt.bz2):

    /usr/include : Directory for standard include files.
    /usr/lib : Libraries for programming and packages
    /usr/lib<qual> : Alternate format libraries (optional)

Думаю так:
- хедерам хорошо бы (should) лежать в /usr/include; если кто-то делает не так,
  возможно, у них есть веские поводы, в которые нам вникать некогда, но без
  собственных веских поводов лучше бы стандарты не нарушать;
- в /usr/lib библиотеки класть нельзя, потому как для biarch тогда их не
  перепаковать и рядом не поставить (для libexec другие правила, как для *bin).

2 dans: если для *mpi были особенные доводы, хорошо бы их сюда.  Но вообще в околонаучной среде встречаются весьма странные софтины и подходы, безоглядно на них ориентироваться в качестве примера совсем не стоит.

> [...] если есть желание, чтобы софт работал с любой из версий библиотеки.
> Мы с mike@ так в своё время и порешали (сейчас уже не вспомню, что это был
> за софт, но он работает и у него с seq-версией nethdf5, и у меня
> с mpi-версией), что по умолчанию такое поведение предпочтительно.
Кажется, grace.

"PreScriptum: давайте спросим знатоков, вдруг кто найдёт время и объяснение."

Нужно будет потом найти время на пересборку всего этого хозяйства. Я - пас, говорю сразу. Почему, будет ясно ниже.

"Думаю так:
- хедерам хорошо бы (should) лежать в /usr/include; если кто-то делает не так,
  возможно, у них есть веские поводы, в которые нам вникать некогда, но без
  собственных веских поводов лучше бы стандарты не нарушать;"

Ну хорошо, можно пройтись (а лучше заставить это сделать repocop), чтобы он нашёл все такие пакеты-нарушители и громко на них ругался. Следствие: сколько _зависимых_ пакетов придётся пересобирать? Мне страшно даже примерно прикидывать. Но даже не это самое страшное.

"- в /usr/lib библиотеки класть нельзя, потому как для biarch тогда их не
  перепаковать и рядом не поставить (для libexec другие правила, как для *bin)."

Не понял?

"2 dans: если для *mpi были особенные доводы, хорошо бы их сюда."

Почему не в %_libdir, а в %_libexecdir, не знаю, да и не интересовался особо, ибо работает хорошо и на i586, и на x86_64, возражений не было ни у кого, никто за целый год об этом не заявил (только в этом обсуждении, да и то в виде вопроса). А вот у меня один вопрос и одна реплика:

a. Зачем пытаться обеспечивать biarch для пакетов, которые на обоих архитектурах нормально собираются и работают?

b. Миш, ну вот переложит dans@ OpenMPI из %_libexecdir в %_libdir (попутно и хэдеры из %_libexecdir/openmpi/include куда-нибудь в %_includedir/openmpi), а какие последствия это будет иметь для меня лично (за других не говорю), рассказать? Я целый год в этой схеме работал, и, подчёркиваю, В ОСНОВНОМ на эту схему (ибо кластер, там OpenMPI - царь, бог и судья в одном лице). В этой ситуации сборка python 2.6 мне покажется пикником где-нибудь на Багамах. Это считай начинать с нуля, делая по-новой _годовую_ работу. Если дойдёт до этой необоходимости, мне ничего не останется, как перевесить _все_ кластерные пакеты на @nobody :(

> [...] если есть желание, чтобы софт работал с любой из версий библиотеки.
> Мы с mike@ так в своё время и порешали (сейчас уже не вспомню, что это был
> за софт, но он работает и у него с seq-версией nethdf5, и у меня
> с mpi-версией), что по умолчанию такое поведение предпочтительно.
Кажется, grace."

Точно, она, милая. До сих пор у меня не стоит seq-версии библиотек nethdf5 и netcdf, только mpi, чему я рад, потому что лишнего хлама нет, mpi-версии со своими задачами справляются не хуже.

Порекомендовали напомнить, что БОЛЬШИНСТВО моих библиотек линкуется с библиотеками из %_libexecdir/openmpi/lib/*

И часть своих тоже лежит в %_libexecdir/%name/lib, ибо собраны различными способами для различных нужд. Скажем, тот же PETSc собран для работы с реальными и комплексными числами, и ряд пакетов также собраны для разных версий PETSc. Я убьюсь, пока буду переделывать всё это под _новые_ для меня требования. Мне будет проще, комфортней и быстрей оставить всё как есть, благо форк сизифа я никуда не девал, живёт, родимый.

Просто будет обидно, что так много работы _для_других_ - просто коту под хвост, и времени потраченного жалко (год).

(В ответ на комментарий №16)
> "Думаю так:
> - хедерам хорошо бы (should) лежать в /usr/include; если кто-то делает не так,
>   возможно, у них есть веские поводы, в которые нам вникать некогда, но без
>   собственных веских поводов лучше бы стандарты не нарушать;"

несколько реализаций стандарта MPI с чуть разными хедерами.
есть возможность перенести  /usr/include/%package
все, кто использует кошерный способ сборки через врапперы "mpi*", этого даже и не заметят.
к сожалению встречаются отдельные пакеты и пользователи кластеров, которые могут использовать компиляцию без врапперов - им может снести крышу.

> Ну хорошо, можно пройтись (а лучше заставить это сделать repocop), чтобы он
> нашёл все такие пакеты-нарушители и громко на них ругался. Следствие: сколько
> _зависимых_ пакетов придётся пересобирать? Мне страшно даже примерно
> прикидывать. Но даже не это самое страшное.

а что тогда страшное ?

> "- в /usr/lib библиотеки класть нельзя, потому как для biarch тогда их не
>   перепаковать и рядом не поставить (для libexec другие правила, как для
> *bin)."
> 
> "2 dans: если для *mpi были особенные доводы, хорошо бы их сюда."


> Почему не в %_libdir, а в %_libexecdir, не знаю, да и не интересовался особо,
> ибо работает хорошо и на i586, и на x86_64, возражений не было ни у кого, никто
> за целый год об этом не заявил (только в этом обсуждении, да и то в виде
> вопроса).

по поводу mpi заглянул в историю - уже 2 года. корни надо искать в подготовке дистрибутива для Skif'a. именно тогда был введен mpi-selector и сделан перенос в %_libexecdir.

Здесь небольшое лирическое отступление: насколько мне известно на многих кластерах используется несколько реализаций mpi, которые, по историческим причинам группируются в каком-либо одном месте со всеми своими библиотеками,заголовочными и другими файлами. часто в /opt. у нас таким местом стало %_libexecdir.

> А вот у меня один вопрос и одна реплика:
> a. Зачем пытаться обеспечивать biarch для пакетов, которые на обоих
> архитектурах нормально собираются и работают?

хе. добавлю от себя риторический вопрос - зачем для них вообще i586 ? ;-)

> b. Миш, ну вот переложит dans@ OpenMPI из %_libexecdir в %_libdir (попутно и
> хэдеры из %_libexecdir/openmpi/include куда-нибудь в %_includedir/openmpi), а
> какие последствия это будет иметь для меня лично (за других не говорю),
> рассказать? Я целый год в этой схеме работал, и, подчёркиваю, В ОСНОВНОМ на эту
> схему (ибо кластер, там OpenMPI - царь, бог и судья в одном лице). 

2real@: глянул на несколько твоих пакетов... м-да... понимаю твое нежелание все переносить. хотя перенос include, вроде отразится не должен.

насколько я понимаю сейчас все данные, относящиеся к кластерному пакету сгруппированы в одном месте: %_libexecdir/%name/{bin,data,include,lib,man} и разносить на 
/usr/{include,%_lib,share,share/man}/%name крайне не хотелось бы, причем куда деть bin - даже не предположу.
Хотя %_libexecdir, возможно, не лучшее место для всего этого хозяйства, но и %_libdir не самое подходящее.

резюмируя:
минусы текущего размещения кластерных пакетов:
1. нарушен FHS
2. невозможен biarch
по 1 - многие кластерные пакеты его все рано нарушают и фиксить за мэйнстримом никакого real@ не хватит; по 2 - biarch не нужен в принципе, т.к. на кластер стараются ставить софт максимально оптимизированный под узлы. На данный момент это x86_64.

С другой стороны - геморрой по пересборке и последующей поддержке согласно стандартам кучи пакетов, мэйнстрим которых просто пишет необходимый им софт не заморачиваясь на всякие там стандарты.

Как по мне - овчинка выделки не стоит.

Я больше вопросов не имею.

"Несколько реализаций стандарта MPI с чуть разными хедерами.
есть возможность перенести  /usr/include/%package
все, кто использует кошерный способ сборки через врапперы "mpi*", этого даже и
не заметят."

Когда я проходил процедуру @join, мне объясняли только самые азы сборки пакетов (и то потом в devel@ на смех поднимали за эти "азы"), а такие тонкости, как сборки rpm-пакетов mpi, да плюс ещё в специфике ALT Linux, никто объяснять не удосуживался, информации никакой нигде нет, эталонного пакета, на который я бы опирался, тоже нет. В таких случаях приходится действовать как обычно: изобретая свой велосипед.

"к сожалению встречаются отдельные пакеты и пользователи кластеров, которые
могут использовать компиляцию без врапперов - им может снести крышу."

Ладно хедеры, им можно крышу поправить, а вот с RPATH всё намного печальней. И когда таких пакетов - сотни.

"а что тогда страшное ?"

Абзац выше.

"> А вот у меня один вопрос и одна реплика:
> a. Зачем пытаться обеспечивать biarch для пакетов, которые на обоих
> архитектурах нормально собираются и работают?
хе. добавлю от себя риторический вопрос - зачем для них вообще i586 ? ;-)"

Не все вузы одинаково богаты, есть и те, где на кластерах до сих пор %ix86, причём много и таких, которые в учебное время используются как рабочие станции.

"2real@: глянул на несколько твоих пакетов... м-да... понимаю твое нежелание все
переносить."

Видимо, собрано не так, как задумывалось 2 года назад. Можно на конкретном примере - http://git.altlinux.org/people/real/packages/mpip.git , показать, как переделать пакет так, чтобы с ним не пришлось мучиться при смене положения хедеров MPI и, что на порядки важнее, смене положения mpi-библиотек? Ну и, полагаю, там и не только с этой позиции есть что улучшить. Да такому тексту на вики цены не будет.

Добавлю ещё, что учитывая, что mpich в сизифе нет, mvapich для ethernet-кластеров не подходят, а lam - это что-то такое, что лучше не вспоминать, поэтому я не ставил задачи (да и возможно ли её реализовать в наших условиях?) сборку для использования с разными реализациями MPI и остановился на OpenMPI как наиболее приемлемом у нас варианте.

"насколько я понимаю сейчас все данные, относящиеся к кластерному пакету
сгруппированы в одном месте: %_libexecdir/%name/{bin,data,include,lib,man} и
разносить на "

Ну, маны я пока куда надо пихаю ;)

"biarch не нужен в принципе, т.к. на кластер
стараются ставить софт максимально оптимизированный под узлы. На данный момент
это x86_64."

Я выше немного отметился на этот счёт, но тут добавлю, что кластерные пакеты в сизифе все собраны для i586/x86_64, и никакой биарч им никуда не упёрся.

Раз тема свёрнута, RESOLVED - WONTFIX.