[devel] [spec-lynch]

[Damir Shayhutdinov]

9 октября 2009 г. 20:03 пользователь Евгений Ростовцев
<real.altlinux.org> написал:
> http://git.altlinux.org/people/real/packages/trilinos.git?p=trilinos.git;a=blob_plain;f=trilinos.spec;hb=HEAD
>
> Спек ужасен по объёму, так что на быстрый ответ не расчитываю. Просто,
> надеюсь, разбор пройдёт относительно бесконфликтно (т.е. без личных
> претензий, сугубо в рабочем режиме). Причины тех или иных мест в спеке
> поясню в процессе обсуждения, а вот на полную вычистку спека до сих
> пор не могу себя простимулировать (очень долго получилось бы), но в
> случае обсуждения надеюсь заняться.

Привет!
Присланная ссылка со спеком не очень удобна для разбора, поэтому я ее
заменил на такую:
http://git.altlinux.org/people/real/packages/trilinos.git?p=trilinos.git;a=blob;f=trilinos.spec;hb=HEAD
Там удобнее ссылаться на строчки.

  17 Source: http://trilinos.sandia.gov/download/files/trilinos-9.0.3.tar.gz
Скорее всего имеет смысл заменить  trilinos-9.0.3 на %name-%version,
меньше будет измененных строчек при обновлении.

В спеке длиной 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

Непонятно, что делает такая структура, для чего нужна. Раньше были
пакеты с другим именем, которые Provides: lib%name-devel? Иначе, при
отсутствии AllowDuplicates, эти Conflicts и Obsoletes на тот же пакет,
но меньшей версии не нужны. И так кстати почти во всех девел-пакетах.

В 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?

По идее, при Requires с жесткой версией, Conflicts и Obsoletes не
нужны (если не брать в рассчет AllowDuplicates, но это для
-devel-пакетов в основном бессмысленно)

То же самое касается строчек 176 и 177. В строчке 176 делается жесткий
Requires, поэтому в 177 строчке конфликт не нужен.

Аналогичные замечания по всем остальным пакетам пропущены

Теперь по сборке.

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

В идеале секция %build должна состоять из %configure (возможно,
большого, так как присутствует очень много опций), с вариациям по
%with/%enable.

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), и поэтому особенно
уязвима перед изменениями исходников.

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

Вообще, по-хорошему, секция %build не должна менять исходники, для
этого есть секция %prep. Если запустить отдельно секцию %build (через
--short-circuit), то сборка должна проходить с одними и теми же
исходниками.

2693 pushd packages/zoltan/siMPI
2694 %make_build
2695 popd
Можно было бы заменить на
        %make_build -C packages/zoltan/siMPI
То же самое в 2740-2742, 2802-2804,

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

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

Секция %install тоже выглядит как Makefile и просто напрашивается на
перенос в исходники проекта.

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 нужен на этапе
компиляции, а не на этапе установки. Когда линкер линкует библиотеку к
другой библиотеке, или к исполняемому файлу, он смотрет, задан ли
SONAME. Если задан, то линкер использует этот SONAME вместо имени
библиотеки (которое тут равно libfoo.so). Это позволяет получить
конечный бинарник, в котором зависимости идут по libfoo.so.%sover, а
не на libfoo.so, как это бывает в случае без soname.

В данном случае, если компиляция библиотек производилась без заданий
SONAME, создание  таких "сонейм-симлинков" бессмысленно. Карго-soname
не помогут, а только запутают пользователей. Проще не переименовывать
библиотеки, а в devel-пакеты включать только заголовочные файлы.
Если интересно - посмотрите на пакет libnss и libnss-devel

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.

> Я, например, подумываю о том, чтобы все хедеры засунуть в один пакет,
> отдельный, типа trilinos-headers, без всяких .so. Сейчас просто из-за
> того, что в некоторых хедерах есть директивы включения из других
> пакетов, зависимости получились такими жёсткими, что устанавливаются
> вообще почти все devel-пакеты, что нежелательно...

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

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