Re: [devel] [spec-lynch]

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

Re: [devel] [spec-lynch]

[Slava Semushin]

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

Так ли уж необходимо заменять имя программы на %name? (Особенно в Source)

Склоняюсь к мысли, что использование %name в Source, Patch и,
особенно, в Url неоправданно и иной раз создаёт неудобства. Имя
программы, как правило, не изменяется, а читабельности этот %name не
сильно-то придаёт, так что не вижу смысла его использовать в данном
случае.

(Основано на собственном опыте, когда несколько раз копировал адрес из
Url/Source в браузер и приходилось везде %name заменять на имя
программы.)

[...]

-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] [spec-lynch]

[Alexey Rusakov]

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

В Вск, 11/10/2009 в 18:40 +0700, Slava Semushin пишет:
> 10 октября 2009 г. 17:29 пользователь Damir Shayhutdinov
> <damir@altlinux.org> написал:
> [...]
> >  17 Source: http://trilinos.sandia.gov/download/files/trilinos-9.0.3.tar.gz
> > Скорее всего имеет смысл заменить  trilinos-9.0.3 на %name-%version,
> > меньше будет измененных строчек при обновлении.
> 
> Так ли уж необходимо заменять имя программы на %name? (Особенно в Source)
> 
> Склоняюсь к мысли, что использование %name в Source, Patch и,
> особенно, в Url неоправданно и иной раз создаёт неудобства. Имя
> программы, как правило, не изменяется, а читабельности этот %name не
> сильно-то придаёт, так что не вижу смысла его использовать в данном
> случае.
> 
> (Основано на собственном опыте, когда несколько раз копировал адрес из
> Url/Source в браузер и приходилось везде %name заменять на имя
> программы.)
rpmurl наше всё. С номером версии всё равно ничего не поделать, править
его каждый раз замаешься, и главное, это нарушает DRY-принцип[1]. Зато я
уже много раз копировал стандартные для SourceForge и gnome.org Url'ы к
тарболлам в очень разные спеки. Благодаря конструкциям вида
%gnome_ftp/%name/%version/%name-%version.tar.bz2

[1] http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] [spec-lynch]

[REAL]

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

Привет!

10.10.09, Damir Shayhutdinov<damir@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 Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] [spec-lynch]

[Boris Savelev]

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

вот я тоже как-то столкнулся с подобным, когда либа с которой
линкуешься лежит не в %_libdir. При этом после линковки с такими
либами, используя rpath, rpm формировал unmet
(https://bugzilla.altlinux.org/show_bug.cgi?id=17843). Как быть?

-- 
Boris

Re: [devel] [spec-lynch]

[REAL]

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

Не поможет.

 > readelf -a /usr/lib64/libpytrilinos.so.0.9 |grep RPATH
  0x000000000000000f (RPATH)              Library rpath: 
[/usr/lib/openmpi/lib:/usr/lib/openmpi/lib/openmpi:path=/usr/lib/openmpi/lib]

И потом, подчёркиваю, нет у этой библиотеки анметов, её бы даже в 
локальном хэшере не удалось упаковать в противном случае.

> вот я тоже как-то столкнулся с подобным, когда либа с которой
> линкуешься лежит не в %_libdir. При этом после линковки с такими
> либами, используя rpath, rpm формировал unmet
> (https://bugzilla.altlinux.org/show_bug.cgi?id=17843). Как быть?

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

-- 

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

Re: [devel] [spec-lynch]

[Michael Shigorin]

On Mon, Oct 12, 2009 at 10:37:57AM +0800, REAL wrote:
> Ну и насчёт указания конкретных ссылок в Source вместо
> %name-%version - так тьютор научил

Кто?? (если что -- я стараюсь не макрифицировать Url:,
использовать %name и %version в Source:, в Patch: --
по обстановке, например, в зависимости от того, ожидается
ли отвал/пересмотр патча "чуть что" или нет)

> >   90 %package -n lib%name-devel
> > .......
> >  105 Conflicts: lib%name-devel < %version-%release
> >  106 Obsoletes: lib%name-devel < %version-%release
> > Непонятно, что делает такая структура, для чего нужна.
> Достаёт ругань репокопа, когда файлы перемещаются из одного
> подпакета в другой, в таких случаях репокоп ругался, что один
> из подпакетов конфликтует с другим подпакетом, но другой версии
> (оба собираются из одного спека); а как избавляться от этой
> ругани, как-то не очёнь чётко до сих пор уяснил. Ну или это
> бага репокопа, сформулировать которую что-то с ходу не
> получается.

Мне кажется, что если "достаёт ругань репокопа", то её стоит
либо игнорировать, либо поинтересоваться (например, здесь) --
что подразумевалось и как предлагается сделать красиво на примере
заданного спека.

Мы здесь не для того, чтоб роботам угождать.  Это они для того,
чтоб нам ляпы подсказывать.

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

Возможно, тогда и не стоит заморачиваться :(
Разве что в %prep перетащить по возможности.

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

Re: [devel] [spec-lynch]

[REAL]

Michael Shigorin пишет:
>> Ну и насчёт указания конкретных ссылок в Source вместо
>> %name-%version - так тьютор научил
> Кто??

Ментор, пардон.

> (если что -- я стараюсь не макрифицировать Url:,
> использовать %name и %version в Source:,

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


> Мне кажется, что если "достаёт ругань репокопа", то её стоит
> либо игнорировать, либо поинтересоваться (например, здесь) --
> что подразумевалось и как предлагается сделать красиво на примере
> заданного спека.

Да здесь нередко уже обсуждались подобные конфликты пакетов самих с 
собой, чем дело кончилось, я так и не понял.

>> Насчёт патча в апстрим: увы, это не такой апстрим, где это бы
>> имело смысл :( (уже проверял).
> 
> Возможно, тогда и не стоит заморачиваться :(
> Разве что в %prep перетащить по возможности.

Ну вообще спек я всё же почищу конкретно, тем более мне часто туда 
смотреть приходится.

-- 

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

Re: [devel] [spec-lynch]

[Michael Shigorin]

On Tue, Oct 13, 2009 at 10:58:57AM +0800, REAL wrote:
> >>Ну и насчёт указания конкретных ссылок в Source вместо
> >>%name-%version - так тьютор научил
> >Кто??
> Ментор, пардон.

Если это был я, то про Source: такого не говорил.

> >(если что -- я стараюсь не макрифицировать Url:,
> >использовать %name и %version в Source:,
> А я уже не знаю, кого слушать, здесь у разных людей свой взгляд
> на сей счёт. К счастью, для меня это редкая проблема, в
> основном собираю из репозиториев, а не из таров.

Это вопрос вкуса, но раз уж зашло -- давайте обдумаем и забросим
на вики (в /Spec?) рекомендации.

> >Мне кажется, что если "достаёт ругань репокопа", то её стоит
> >либо игнорировать, либо поинтересоваться (например, здесь) --
> >что подразумевалось и как предлагается сделать красиво на
> >примере заданного спека.
> Да здесь нередко уже обсуждались подобные конфликты пакетов
> самих с собой, чем дело кончилось, я так и не понял.

В таких случаях предпочитаю переспросить, чем делать-переделывать.
:)

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

Re: [devel] [spec-lynch] trilinos

[Michael Shigorin]

On Tue, Oct 13, 2009 at 03:40:20PM +0800, REAL wrote:
> Но вопрос, конечно, лучше озвучить, раз он возник. Вот есть
> пакет типа libfoo-devel, там внутри статическая библиотека.
> Если возникает реформа и в этот пакет вносится
> shared-библиотека, а статическая уходит в libfoo-devel-static,
> какие конфликты/обсолеты проставлять, чтобы всё работало и спек
> не загаживался?

libfoo-devel-static Obsoletes: libfoo-devel < %change_ver
как минимум даст хинт к тому, что произошло.  Provides: не
соображу, поскольку имя libfoo-devel остаётся.

Думаю, для *-devel* это приемлемо -- всё равно при появлении
разделяемой библиотеки разломы по сборке хорошо бы чинить в
сторону её использования, а не пересовывания статики под новым
именем.

Для избежания можно было сразу делать libfoo-devel-static.
Собсно, это и прописано в секции "Статические библиотеки"
http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/old/rpm_packaging_howto.html

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

Re: [devel] [spec-lynch]

[REAL]

Michael Shigorin пишет:
>>>> Ну и насчёт указания конкретных ссылок в Source вместо
>>>> %name-%version - так тьютор научил
>>> Кто??
>> Ментор, пардон.
> 
> Если это был я, то про Source: такого не говорил.

Нет, не ты :)

>>> (если что -- я стараюсь не макрифицировать Url:,
>>> использовать %name и %version в Source:,
>> А я уже не знаю, кого слушать, здесь у разных людей свой взгляд
>> на сей счёт. К счастью, для меня это редкая проблема, в
>> основном собираю из репозиториев, а не из таров.
> 
> Это вопрос вкуса, но раз уж зашло -- давайте обдумаем и забросим
> на вики (в /Spec?) рекомендации.

Ну вот лично мне как раз удобней прямые ссылки в спеке иметь/видеть. 
Вставить-то совсем не проблема, зато спек читать легче. Но это всё 
мелочь, а вот если не в Source, а в Url попадаются макросы, это 
становится совсем грустно.

>> Да здесь нередко уже обсуждались подобные конфликты пакетов
>> самих с собой, чем дело кончилось, я так и не понял.
> 
> В таких случаях предпочитаю переспросить, чем делать-переделывать.
> :)

Сейчас я вообще убрал те конфликты. Также завернул общую часть 
description в макрос и оптимизировал зависимости. Скоро приступаю к 
переносу сборочной фигни из спека куда подальше (makefiles, *.py), 
только тут один пакет дособираю...

Пакеты с shared-библиотеками существуют уже давно, так что если у кого 
и будет конфликт при обновлении, то у тех, кто вообще с полгода не 
обновлялся. Да и в бранчи Trilinos я не портировал: никто не просил, а 
мне лишняя головная боль (и сильная) как-то не особо нужна.

Но вопрос, конечно, лучше озвучить, раз он возник. Вот есть пакет типа 
libfoo-devel, там внутри статическая библиотека. Если возникает 
реформа и в этот пакет вносится shared-библиотека, а статическая 
уходит в libfoo-devel-static, какие конфликты/обсолеты проставлять, 
чтобы всё работало и спек не загаживался?

-- 

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

Re: [devel] [spec-lynch] trilinos

[Michael Shigorin]

On Tue, Oct 13, 2009 at 03:56:14PM +0800, REAL wrote:
> >Для избежания можно было сразу делать libfoo-devel-static.
> >Собсно, это и прописано в секции "Статические библиотеки"
> >http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/old/rpm_packaging_howto.html
> Там не говорится про случай, когда shared-библиотека
> отсутствует. А вот в другом документе (SharedLibs Policy)
> прописано, что при её отсутствии пакет со статической
> библиотекой должен называться libfoo-devel.

Ух ты, а вот это как-то пропустил.  Притом не так давно
переделывал SimGear-devel в libsimgear-devel-static.

> В общем, от этого разночтения тоже было бы неплохо избавиться.

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

Re: [devel] [spec-lynch] trilinos

[REAL]

Michael Shigorin пишет:
> Для избежания можно было сразу делать libfoo-devel-static.
> Собсно, это и прописано в секции "Статические библиотеки"
> http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/old/rpm_packaging_howto.html

Там не говорится про случай, когда shared-библиотека отсутствует. А 
вот в другом документе (SharedLibs Policy) прописано, что при её 
отсутствии пакет со статической библиотекой должен называться 
libfoo-devel. В общем, от этого разночтения тоже было бы неплохо 
избавиться.

-- 

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

Re: [devel] [spec-lynch] trilinos

[Damir Shayhutdinov]

>> Но вопрос, конечно, лучше озвучить, раз он возник. Вот есть
>> пакет типа libfoo-devel, там внутри статическая библиотека.
>> Если возникает реформа и в этот пакет вносится
>> shared-библиотека, а статическая уходит в libfoo-devel-static,
>> какие конфликты/обсолеты проставлять, чтобы всё работало и спек
>> не загаживался?
>
> libfoo-devel-static Obsoletes: libfoo-devel < %change_ver
> как минимум даст хинт к тому, что произошло.  Provides: не
> соображу, поскольку имя libfoo-devel остаётся.
Provides тут и не нужен.

> Думаю, для *-devel* это приемлемо -- всё равно при появлении
> разделяемой библиотеки разломы по сборке хорошо бы чинить в
> сторону её использования, а не пересовывания статики под новым
> именем.
Тут все зависит от астрима на самом деле. Бывает, что апстрим хоть и
перешел на shared, однако с ABI ведет себя так, как как будто
библиотека все еще static.

Re: [devel] [spec-lynch] trilinos

[Alexey I. Froloff]

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

On Tue, Oct 13, 2009 at 04:24:21PM +0800, REAL wrote:
> Всё это лишние траты времени, и поэтому хотелось бы иметь какой-нибудь 
> инструмент, чтобы определить, что произошёл слом API/ABI, не дожидаясь 
> еженедельной тотальной пересборки сизифа. Есть какие-нибудь варианты?
rpmsodiff например.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [spec-lynch]

[Денис Смирнов]

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

On Tue, Oct 13, 2009 at 10:58:57AM +0800, REAL wrote:

R> Да здесь нередко уже обсуждались подобные конфликты пакетов самих с 
R> собой, чем дело кончилось, я так и не понял.

Есть конфликты фактически (пакеты содержат объекты с одинаковым path), а
есть конфликты с точки зрения метаданных (проставлен conflicts).

Так вот пакет не должен иметь фактических конфликтов без соответствующих
конфликтов в метаданных.

Если некий файл переложили из пакета A в пакет B, то новый пакет B должен
содержать конфликт на старые версии A.

Из этой ситуации есть исключение -- если этот конфликт косвенный. Например
пакеты A и B создаются из одного спека, и один из них имеет requires на
конкретную версию другого. 

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [spec-lynch] trilinos

[Damir Shayhutdinov]

> Всё это лишние траты времени, и поэтому хотелось бы иметь какой-нибудь
> инструмент, чтобы определить, что произошёл слом API/ABI, не дожидаясь
> еженедельной тотальной пересборки сизифа. Есть какие-нибудь варианты?

rpmsodiff из пакета qa-robot. Он проведет дифф по файлам .so. А вот по
include-ам пока диффов нет. Возможно, имеет смысл написать такой,
чтобы отслеживать изменения API.

Re: [devel] [spec-lynch] trilinos

[REAL]

Damir Shayhutdinov пишет:
>> Думаю, для *-devel* это приемлемо -- всё равно при появлении
>> разделяемой библиотеки разломы по сборке хорошо бы чинить в
>> сторону её использования, а не пересовывания статики под новым
>> именем.
> Тут все зависит от астрима на самом деле. Бывает, что апстрим хоть и
> перешел на shared, однако с ABI ведет себя так, как как будто
> библиотека все еще static.

У меня довольно немало пакетов, где shared-библиотеки вовсе не 
предусмотрены, я их делаю сам, так что и за разломами приходится 
следить самому. Или, вот как недавно с libqwt приключилось: API+ABI 
поменялось, а soname осталось прежним, пришлось самостоятельно её 
(soname) менять.

Всё это лишние траты времени, и поэтому хотелось бы иметь какой-нибудь 
инструмент, чтобы определить, что произошёл слом API/ABI, не дожидаясь 
еженедельной тотальной пересборки сизифа. Есть какие-нибудь варианты?

-- 

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

Re: [devel] [spec-lynch] trilinos

[REAL]

Damir Shayhutdinov пишет:
>> Всё это лишние траты времени, и поэтому хотелось бы иметь какой-нибудь
>> инструмент, чтобы определить, что произошёл слом API/ABI, не дожидаясь
>> еженедельной тотальной пересборки сизифа. Есть какие-нибудь варианты?
> rpmsodiff из пакета qa-robot. Он проведет дифф по файлам .so.

Отлично.

> А вот по
> include-ам пока диффов нет. Возможно, имеет смысл написать такой,
> чтобы отслеживать изменения API.

Смотрю, это скрипт. Наверно, не так и сложно будет написать по 
аналогии. rpmhdiff? :)

-- 

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