[devel] [spec-lynch]

[REAL]

С gmail письма модератор не пропустил, дублирую с работы.

Привет!

10.10.09, Damir Shayhutdinov<damir at altlinux.org> написал(а):
 >   17 Source: 
http://trilinos.sandia.gov/download/files/trilinos-9.0.3.tar.gz
 > Скорее всего имеет смысл заменить  trilinos-9.0.3 на %name-%version,
 > меньше будет измененных строчек при обновлении.

Насчёт обновлений есть вероятность, что придётся собирать вообще из
другого спека. Дело в том, что я пока вглубь будущего релиза не
смотрел, но уже видно, что там будет CMake, а не autotools. Также
предполагаются довольно сильные изменения в самих исходниках. В любом
случае, пакет уже будет другой (в смысле как это описано Вами же, по
поводу слома API+ABI).

Ну и насчёт указания конкретных ссылок в Source вместо %name-%version
- так тьютор научил, а учитывая, что Trilinos я начал собирать уже
давно, эта ссылка так и сохранилась.

 > В спеке длиной 3600 строчек тяжело разбираться. В принципе, длину
 > спека можно было бы немного уменьшить, увеличив читабельность, если
 > общие 6 строчек (45-50), которые появляются в каждом %description,
 > оформить в виде макроса. А вообще нужны эти 6 строчек в каждом
 > описании каждого подпакета?

Обычно стараюсь эти строчки сохранять, чтобы не приходилось потом по
кучке подпакетов бегать, выясняя, для чего искомый пакет нужен. Просто
потому, что самому так удобней, когда дело касается чужих пакетов. А
макрос - его прямо в спеке в самое начало, видимо, поместить?

 >   90 %package -n lib%name-devel
 > .......
 >  105 Conflicts: lib%name-devel < %version-%release
 >  106 Obsoletes: lib%name-devel < %version-%release
 >
 > Непонятно, что делает такая структура, для чего нужна.

Достаёт ругань репокопа, когда файлы перемещаются из одного подпакета
в другой, в таких случаях репокоп ругался, что один из подпакетов
конфликтует с другим подпакетом, но другой версии (оба собираются из
одного спека); а как избавляться от этой ругани, как-то не очёнь чётко
до сих пор уяснил. Ну или это бага репокопа, сформулировать которую
что-то с ходу не получается.

 > В libisorropia-devel наблюдается следующее:
 >
 >
 >  151 %package -n libisorropia-devel
 > ....
 >  155 Requires: lib%name-devel = %version-%release
 > .....
 >  159 Conflicts: lib%name-devel < %version-%release
 >  160 Obsoletes: lib%name-devel < %version-%release
 >
 > Нет ли ошибки в строчках 159-160? Не подразумевался ли там
 > libisorropia-devel вместо lib%name-devel?

Некоторые файлы были из libtrilinos-devel перемещены в
libisorropia-devel. Точнее даже - раньше пакета libisorropia[-devel]
вообще не было.

 > Строчки 2495-2521 видимо нужны, потому что ./configure не справляется
 > с автоопределением местоположения заголовков и библиотек?

Увы, не справляется. Там configure/Makefile вообще много с чем не
справляется (особенно забавно, что shared-библиотеки собираются только
при сборке python-wrapper'а, иначе - только static).

 > Возможно,
 > правильнее будет доработать ./configure и отослать патч в апстрим, а
 > не делать костыли в спеке, тем более что их там так много.

Да, я со временем это уже понял, и понял, как это делается. Так что
буду переделывать. Боюсь, без подобного обсуждения всё бы осталось
по-прежнему (стимула не было, работа-то долгая предстоит).

Насчёт патча в апстрим: увы, это не такой апстрим, где это бы имело
смысл :( (уже проверял).

 > 2674 %if_with petsc
 > 2675 pushd packages/epetraext
 > 2676 sed -i 's|^clean::|clean2:|' petscconf
 > 2677 popd
 > 2678 sed -i '162s|#||' packages/PyTrilinos/shared/setup.py
 > 2679 %endif
 >
 > Зачем pushd/popd в строчках 2675/2677? Можно было бы просто написать
 > sed -i <....> packages/epetraext/petscconf

Наследие экспериментов, уберу.

 > Строчка
 > 2678 sed -i '162s|#||' packages/PyTrilinos/shared/setup.py
 > содержит четкое указание на номер строки (162), и поэтому особенно
 > уязвима перед изменениями исходников.

Тут выше уже писал, что при обновлении в апстриме будет вообще почти с
нуля спек писаться (не считая того, что до секции %prep). Но вообще, я
позднее в таких случаях нчал добавлять в такие файлы конструкции вида
@СТРОКА@, чтобы перед сборкой её sed'ом подменять.

 > Предлагаю оформить эти sed-ы в виде патча, который будет применяться,
 > если собирается с petsc, еще на этапе %prep, после %setup. Так будет
 > гораздо проще, и в спеке будет меньше мусора.

OK.

 > Вообще спек в этом месте до ужаса напоминает Makefile. 2697-2735 уж
 > точно должны быть в каком-нибудь Makefile, а вовсе не в спеке.

Так и сделаю со временем, всё равно скоро будет очередной подход к
снаряду: уже есть потребность в пакете PySundance, который ещё и
чинить придётся.

 > Смущает также строчка 2717 и --no-as-needed в ней. Без такого костыля
 > сборка не удается?

Было что-то с недолинковкой, которую иным способом пока не получалось
победить. Строка 2766 появилась позже, а я, честно говоря, с таким
вариантом ещё не пробовал убирать --no-as-needed.

 > 2828 pushd %buildroot%_libdir
 > 2829 for i in $(ls *.so); do
 > 2830         mv $i $i.%sover
 > 2831         ln -s $i.%sover $i
 > 2832 done
 > 2833 popd
 >
 > Это - пример непонимания, как работает soname. Soname нужен на этапе
 > компиляции, а не на этапе установки.

Без файлов .so не работают линковки типа -lИМЯ.

 > Когда линкер линкует библиотеку к
 > другой библиотеке, или к исполняемому файлу, он смотрет, задан ли
 > SONAME. Если задан, то линкер использует этот SONAME вместо имени
 > библиотеки (которое тут равно libfoo.so).

Тут оно равно libfoo.so.0.9

 > readelf -a /usr/lib/libnoxepetra.so |grep soname
  0x0000000e (SONAME)                     Library soname: 
[libnoxepetra.so.0.9]

 > 2862 pushd packages/zoltan/siMPI
 > 2863 %makeinstall_std
 > 2864 popd
 > Тут опять, можно было воспользоваться ключом -C у make.

Хорошо.

 > В общем и целом, спек представляет собой попытку исправить сборочную и
 > установочную обвязку апстрима. Выглядит это некрасиво. Если не бояться
 > патчей, то спек скорее всего удастся причесать к стандартному
 >
 > %prep
 > %setup
 > %patchN...
 > %if_with foo
 >     %patchM
 > %endif
 >
 > %build
 > %configure [куча параметров]
 > %make_build
 >
 > %install
 > %makeinstall_std
 >
 > Думаю, мантейнеры других дистрибутивов тоже будут рады, если подобный
 > патч уйдет в upstream.

sandia вообще редко на такое реагирует :(
(на моей памяти - в 2009 году ни разу)

 > Главное, что нужно обеспечить при таком засовывании заголовочных
 > файлов в один пакет - чтобы софт, который будет собираться с этими
 > библиотеками, мог указывать BuildRequires: libfoo-devel, без знаний, в
 > каком пакете лежат заголовочные файлы. То есть libfoo-devel должен
 > Requires: trilnos-headers и libfoo.

Именно это и предполагается. Остальные Requires планирую
минимизировать, пройдясь по всем библиотекам на предмет ldd.

PS. Благодарю за подробный ответ.

---

 >> Смущает также строчка 2717 и --no-as-needed в ней. Без такого костыля
 >> сборка не удается?
 >
 > Было что-то с недолинковкой, которую иным способом пока не получалось
 > победить. Строка 2766 появилась позже, а я, честно говоря, с таким
 > вариантом ещё не пробовал убирать --no-as-needed.

Вспомнил, здесь строка 2766 не поможет. Просто нужна линковка с .so
OpenMPI в каталоге /usr/lib/openmpi/lib/openmpi

Без --no-as-needed оно ни в какую не линкуется. При этом сборка
проходит нормально, а вот в рантайме идёт сплошная ругань на
отсутствующие символы. Это вообще беда питона при использовании
OpenMPI: вроде всё нормально собирается, но не работает. Кроме как
--no-as-needed я не знаю способа это победить. Даже после разговоров с
мейнтейнером OpenMPI.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ