[devel] rpm packages building

[devel] rpm packages building

[Andrey Astafiev]

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

1. если программный продукт - библиотека, каким из пакетов
следует даввать префикс lib и нужно ли это делать вообще?
например, я делаю пакеты
 а) с разделяемой библиотекой
 б) с файлами заголовков
 в) со статической библиотекой
 г) с документацией
 д) с примерами программ.
для конретного случая, где нужно использовать префикс lib?

2. в каких случаях нужно/можно/желательно
выносить документацию в отдельный пакет?

3. какие существуют способы определения зависимостей для
всех бинарников и библиотек пакетов?
в исправленном спеке для пакета flac я нашел такую строку.
как она добавилась автоматически?
+# Automatically added by buildreq on Wed Aug 08 2001
+BuildRequires: glib-devel gtk+-devel nasm XFree86-devel xmms-devel



~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Stanislav Ievlev]

Andrey Astafiev wrote:

>начал собирать пакет id3lib для работы тегами ID3v1 и ID3v2.
>возникли следующие вопросы:
>
>1. если программный продукт - библиотека, каким из пакетов
>следует даввать префикс lib и нужно ли это делать вообще?
>например, я делаю пакеты
> а) с разделяемой библиотекой
> б) с файлами заголовков
> в) со статической библиотекой
> г) с документацией
> д) с примерами программ.
>для конретного случая, где нужно использовать префикс lib?
>

Если эту библиотеку можно использовать для разработки сторонних программ 
то обычно делится
1. программа  или общая часть библиотеки (например конфигурационные файлы)
2. lib%name - библиотека
3. lib%name-devel - для разработки
4. lib%name-devel-static - необязательно, но если есть, то лучше вынести.

>
>
>2. в каких случаях нужно/можно/желательно
>выносить документацию в отдельный пакет?
>
Если ее очень много и без нее можно прожить. Например grub-doc отдельно 
именно из-за этого.

>
>3. какие существуют способы определения зависимостей для
>всех бинарников и библиотек пакетов?
>в исправленном спеке для пакета flac я нашел такую строку.
>как она добавилась автоматически?
>+# Automatically added by buildreq on Wed Aug 08 2001
>+BuildRequires: glib-devel gtk+-devel nasm XFree86-devel xmms-devel
>
Это программа buildreq добавила

>
>
>
>
>~~~~~~
>andrei
>ICQ: 111752051
>_______________________________________________
>Devel mailing list
>Devel@linux.iplabs.ru
>http://www.logic.ru/mailman/listinfo/devel
>



_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Andrey Astafiev]

> >3. какие существуют способы определения зависимостей для
> >всех бинарников и библиотек пакетов?
> >в исправленном спеке для пакета flac я нашел такую строку.
> >как она добавилась автоматически?
> >+# Automatically added by buildreq on Wed Aug 08 2001
> >+BuildRequires: glib-devel gtk+-devel nasm XFree86-devel xmms-devel
> >
> Это программа buildreq добавила
она вызывается как-то отдельно? эта строка появилась в пакете,
исправленном Дмитрием Левиным. когда я собирал пакет ее не было.

~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Alexander Bokovoy]

On Fri, Aug 10, 2001 at 01:54:41PM +0400, Andrey Astafiev wrote:
> > >3. какие существуют способы определения зависимостей для
> > >всех бинарников и библиотек пакетов?
> > >в исправленном спеке для пакета flac я нашел такую строку.
> > >как она добавилась автоматически?
> > >+# Automatically added by buildreq on Wed Aug 08 2001
> > >+BuildRequires: glib-devel gtk+-devel nasm XFree86-devel xmms-devel
> > >
> > Это программа buildreq добавила
> она вызывается как-то отдельно? эта строка появилась в пакете,
> исправленном Дмитрием Левиным. когда я собирал пакет ее не было.
Поставьте пакет buildreqs и периодически перед сборкой прогоняйте 
buildreq мой_spec_файл
-- 
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
  `Senior software developer and analyst for SaM-Solutions Ltd.`
---
lp1 on fire
(One of the more obfuscated kernel messages)
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Andrey Astafiev]

> >начал собирать пакет id3lib для работы тегами ID3v1 и ID3v2.
> >возникли следующие вопросы:
> >
> >1. если программный продукт - библиотека, каким из пакетов
> >следует даввать префикс lib и нужно ли это делать вообще?
> >например, я делаю пакеты
> > а) с разделяемой библиотекой
> > б) с файлами заголовков
> > в) со статической библиотекой
> > г) с примерами программ.
> >для конретного случая, где нужно использовать префикс lib?
> 
> Если эту библиотеку можно использовать для разработки сторонних программ
> то обычно делится
> 1. программа  или общая часть библиотеки (например конфигурационные
> файлы)
> 2. lib%name - библиотека
> 3. lib%name-devel - для разработки
> 4. lib%name-devel-static - необязательно, но если есть, то лучше
> вынести.

в данном случае ничего общего (попадающего под первую категорию) не находится.
соответственно, нет ничего для пакета главного пакета с именем id3lib.
возможно ли это идеологически? как мне кажется, в данном случае нужно
libid3lib, libid3lib-devel, libid3lib-devel-static и id3lib-examples.
должно ли быть нечто в простой библиотеке, предназначенной только для
использования в других программах, что можно записать в пакет в таким именем?
прилагаю свой спек, с помощью которого я получаю пакеты с вышеуказанными
именами. сборка проходит чисто. укажите, пожалуйста, на корявости.


~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Andrey Astafiev]

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

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

~~~~~~
andrei
ICQ: 111752051

[-- Attachment #2: id3lib.spec --]
[-- Type: application/octet-stream, Size: 3777 bytes --]

Re: [devel] rpm packages building

[Dmitry V. Levin]

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

On Fri, Aug 10, 2001 at 02:58:10PM +0400, Stanislav Ievlev wrote:
> После беглого просмотра
> %post -n %name -p /sbin/ldconfig наверное должен быть к lib%name
> 
> На всякий случай лучше писать *.so.* вместо *.so*
> 
> для %package -n %name-examples (достаточно %package examples)
> 
> Requires лучше lib%name = %version-%release (то есть с релизом как Вы 
> сделали и для остальных пакетов)

А также:
вместо строки
CXXFLAGS="$RPM_OPT_FLAGS -fexceptions"
лучше написать
%remove_optflags %optflags_nocpp
(по умолчанию и так есть -fexceptions, цель: убрать
-fno-exceptions -fno-rtti, если их кто-то выставил).

Я придерживаюсь той же точки зрения, что и Михаил:
В библиотечном пакете очень неудачно выглядит дублирование lib*lib.
Я бы рекомендовал не плодить таких неуклюжестей ни Вам, ни другим
разработчикам.

Вопрос к разработчикам: 
Как бы вы отнеслись к тому, чтобы сделать это правило обязательным для
Sisyphus? Сейчас там находятся следующие lib*lib'ы:
libglib2-1.3.6-alt1
libglib2-devel-1.3.6-alt1
libglib2-devel-static-1.3.6-alt1
libglibwww1-0.2-ipl3mdk
libglibwww1-devel-0.2-ipl3mdk
libpwlib-1.1.33-alt1
libpwlib-devel-1.1.33-alt1

> А в целом - все просто отлично. Далеко не все из нас могут писать такие 
> аккуратные спеки.

Я повидал на последние несколько лет немало spec-файлов от самых разных
людей, и на этом фоне Ваша работа смотрится очень неплохо.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] rpm packages building

[Andrey Astafiev]

> > После беглого просмотра
> > %post -n %name -p /sbin/ldconfig наверное должен быть к lib%name
> > 
> > На всякий случай лучше писать *.so.* вместо *.so*
> > 
> > для %package -n %name-examples (достаточно %package examples)
> > 
> > Requires лучше lib%name = %version-%release (то есть с релизом как Вы 
> > сделали и для остальных пакетов)
> 
> А также:
> вместо строки
> CXXFLAGS="$RPM_OPT_FLAGS -fexceptions"
> лучше написать
> %remove_optflags %optflags_nocpp
> (по умолчанию и так есть -fexceptions, цель: убрать
> -fno-exceptions -fno-rtti, если их кто-то выставил).

спасибо, всем за науку. есть еще пара вопросов:
1. когда собирается пакет, зависимости проставляются автоматически.
при этом хотелось бы избежать прописывания только одной-двух?
пример, я собрал пакет id3lib и пакет с использующей его
программой easytag. для работы easytag нужна версия id3lib >= 3.7.12,
и это я указываю ручками. однако, из-за того что у меня в системе
установлена версия 3.7.13, автоматически прописывается зависимость
от id3lib-3.7.so.13, что не совсем правильно.
как это правильно обработать?

2. вопрос касательно документации к пакету. есть ли (можно ли сделать)
какой-нибудь макрос, позволяющий нескольким пакетам, создаваемым из
одного srpm, сохранять документацию в одном каталоге.
пример, из одного srpm (ncurses) создается несколько пакетов,
при этом докуметация к нему такова, что ее было бы логично разложить
в несколько пакетов (общая информация, мануалы, руководства для
разработчика, примеры). в случае ncurses такое разделение есть и
документация раскладывается в %doc/ncurses/ и %doc/libncurses-devel/
имхо, это не очень удобно, так как желающий почитать документацию и
посмотреть примеры по ncurses посмотрит в первый каталог и ничего там найдет.
надеюсь я высказался достаточно понятно. еще раз повторю основную идею:
должен быть такой стандартный (удобный) макрос, определенный единообразно
для каждой секции files, чтобы после установки каждого отдельного
пакета докуметация добавлялась в один каталог, например, называемый
/usr/share/doc/имя-основного-пакета.

> Я придерживаюсь той же точки зрения, что и Михаил:
> В библиотечном пакете очень неудачно выглядит дублирование lib*lib.
> Я бы рекомендовал не плодить таких неуклюжестей ни Вам, ни другим
> разработчикам.
> 
> Вопрос к разработчикам: 
> Как бы вы отнеслись к тому, чтобы сделать это правило обязательным для
> Sisyphus? Сейчас там находятся следующие lib*lib'ы:

потому-то я и стал писать, коряво lib*lib как-то выглядит.
хотя с другой стороны в плане систематизации в этом есть
некоторое удобство: при сортировке все библиотеки находятся вместе. 



~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Alexander Bokovoy]

On Mon, Aug 13, 2001 at 02:37:49PM +0400, Andrey Astafiev wrote:
> > > После беглого просмотра
> > > %post -n %name -p /sbin/ldconfig наверное должен быть к lib%name
> > > 
> > > На всякий случай лучше писать *.so.* вместо *.so*
> > > 
> > > для %package -n %name-examples (достаточно %package examples)
> > > 
> > > Requires лучше lib%name = %version-%release (то есть с релизом как Вы 
> > > сделали и для остальных пакетов)
> > 
> > А также:
> > вместо строки
> > CXXFLAGS="$RPM_OPT_FLAGS -fexceptions"
> > лучше написать
> > %remove_optflags %optflags_nocpp
> > (по умолчанию и так есть -fexceptions, цель: убрать
> > -fno-exceptions -fno-rtti, если их кто-то выставил).
> 
> спасибо, всем за науку. есть еще пара вопросов:
> 1. когда собирается пакет, зависимости проставляются автоматически.
> при этом хотелось бы избежать прописывания только одной-двух?
> пример, я собрал пакет id3lib и пакет с использующей его
> программой easytag. для работы easytag нужна версия id3lib >= 3.7.12,
> и это я указываю ручками. однако, из-за того что у меня в системе
> установлена версия 3.7.13, автоматически прописывается зависимость
> от id3lib-3.7.so.13, что не совсем правильно.
> как это правильно обработать?
Исправить пакет так, чтобы версия SO-библиотеки не была привязана к версии
пакета. Такая привязка есть неправильное поведение и должно исправляться в
любом случае, поскольку версия .so меняется при изменении API, которое
врядли произошло при смене минорной версии.

 
-- 
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
  `Senior software developer and analyst for SaM-Solutions Ltd.`
---
Q:	What's buried in Grant's tomb?
A:	A corpse.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Dmitry V. Levin]

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

On Mon, Aug 13, 2001 at 02:37:49PM +0400, Andrey Astafiev wrote:
> 2. вопрос касательно документации к пакету. есть ли (можно ли сделать)
> какой-нибудь макрос, позволяющий нескольким пакетам, создаваемым из
> одного srpm, сохранять документацию в одном каталоге.

%doc полный_путь_к_каталогу_с_документацией

> пример, из одного srpm (ncurses) создается несколько пакетов,
> при этом докуметация к нему такова, что ее было бы логично разложить
> в несколько пакетов (общая информация, мануалы, руководства для
> разработчика, примеры). в случае ncurses такое разделение есть и
> документация раскладывается в %doc/ncurses/ и %doc/libncurses-devel/
> имхо, это не очень удобно, так как желающий почитать документацию и
> посмотреть примеры по ncurses посмотрит в первый каталог и ничего там найдет.
> надеюсь я высказался достаточно понятно. еще раз повторю основную идею:
> должен быть такой стандартный (удобный) макрос, определенный единообразно
> для каждой секции files, чтобы после установки каждого отдельного
> пакета докуметация добавлялась в один каталог, например, называемый
> /usr/share/doc/имя-основного-пакета.

Например, так:
%files one
%dir %_defaultdocdir/%name
%doc %_defaultdocdir/%name/one

%files two
%dir %_defaultdocdir/%name
%doc %_defaultdocdir/%name/two

Достаточно этого, или хочется видеть нечто более красивое?


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] rpm packages building

[Andrey Astafiev]

> > 2. вопрос касательно документации к пакету. есть ли
> > (можно ли сделать) какой-нибудь макрос, позволяющий
> > нескольким пакетам, создаваемым из одного srpm,
> > сохранять документацию в одном каталоге.
> 
> %doc полный_путь_к_каталогу_с_документацией

подчеркиваю, чтобы разные rpm, созданные из одного srpm
сохраняли документацию в ОДНОМ каталоге, т.е. не в
/usr/share/doc/%name, /usr/share/doc/%name-devel и т.д.
а все в /usr/share/doc/%name

> > пример, из одного srpm (ncurses) создается несколько
> > пакетов, при этом докуметация к нему такова, что ее
> > было бы логично разложить в несколько пакетов (общая
> > информация, мануалы, руководства для разработчика, примеры).
> > в случае ncurses такое разделение есть и документация
> > раскладывается в %doc/ncurses/ и %doc/libncurses-devel/
> > имхо, это не очень удобно, так как желающий почитать
> > документацию и посмотреть примеры по ncurses посмотрит
> > в первый каталог и ничего там найдет. надеюсь я высказался
> > достаточно понятно. еще раз повторю основную идею:
> > должен быть такой стандартный (удобный) макрос,
> > определенный единообразно для каждой секции files,
> > чтобы после установки каждого отдельного пакета
> > докуметация добавлялась в один каталог, например,
> > называемый /usr/share/doc/имя-основного-пакета.
> 
> Например, так:
> %files one
> %dir %_defaultdocdir/%name
> %doc %_defaultdocdir/%name/one
> 
> %files two
> %dir %_defaultdocdir/%name
> %doc %_defaultdocdir/%name/two
> 
> Достаточно этого, или хочется видеть нечто более красивое?

я вот залил пакет id3lib


~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Andrey Astafiev]

> > > 2. вопрос касательно документации к пакету. есть ли
> > > (можно ли сделать) какой-нибудь макрос, позволяющий
> > > нескольким пакетам, создаваемым из одного srpm,
> > > сохранять документацию в одном каталоге.
> > 
> > %doc полный_путь_к_каталогу_с_документацией
> 
> 
> я вот залил пакет id3lib

так... на чем ето мы остановились? так вот...
в нем примерно реализовано то, что я хотел за
исключением одной вещи. неудобно писать в каталог
%doc %_defaultdocdir/%name
хотелось бы, чтобы мог отработать макрос типа
%doc %_defaultdocdir/%name/{AUTHORS,TODO,README,INSTALL}
можно такое? у меня не получилось.

~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] rpm packages building

[Anton Farygin]

 > > 2. вопрос касательно документации к пакету. есть ли
 > > (можно ли сделать) какой-нибудь макрос, позволяющий
 > > нескольким пакетам, создаваемым из одного srpm,
 > > сохранять документацию в одном каталоге.
 >
 > %doc полный_путь_к_каталогу_с_документацией

подчеркиваю, чтобы разные rpm, созданные из одного srpm
сохраняли документацию в ОДНОМ каталоге, т.е. не в
/usr/share/doc/%name, /usr/share/doc/%name-devel и т.д.
а все в /usr/share/doc/%name

 > > пример, из одного srpm (ncurses) создается несколько
 > > пакетов, при этом докуметация к нему такова, что ее
 > > было бы логично разложить в несколько пакетов (общая
 > > информация, мануалы, руководства для разработчика, примеры).
 > > в случае ncurses такое разделение есть и документация
 > > раскладывается в %doc/ncurses/ и %doc/libncurses-devel/
 > > имхо, это не очень удобно, так как желающий почитать
 > > документацию и посмотреть примеры по ncurses посмотрит
 > > в первый каталог и ничего там найдет. надеюсь я высказался
 > > достаточно понятно. еще раз повторю основную идею:
 > > должен быть такой стандартный (удобный) макрос,
 > > определенный единообразно для каждой секции files,
 > > чтобы после установки каждого отдельного пакета
 > > докуметация добавлялась в один каталог, например,
 > > называемый /usr/share/doc/имя-основного-пакета.
 >
 > Например, так:
 > %files one
 > %dir %_defaultdocdir/%name
 > %doc %_defaultdocdir/%name/one
 >
 > %files two
 > %dir %_defaultdocdir/%name
 > %doc %_defaultdocdir/%name/two
 >
 > Достаточно этого, или хочется видеть нечто более красивое?

я вот залил пакет id3lib


~~~~~~
andrei
ICQ: 111752051
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

[devel] Re: rpm packages building

[Mikhail Zabaluev]

Hello Stanislav,

On Fri, Aug 10, 2001 at 02:45:58PM +0400, Stanislav Ievlev wrote:
>
> >в данном случае ничего общего (попадающего под первую категорию) не находится.
> >соответственно, нет ничего для пакета главного пакета с именем id3lib.
> >возможно ли это идеологически?
> >
> 
> Да. Могут быть только одни lib*.
> 
> > как мне кажется, в данном случае нужно
> >libid3lib, libid3lib-devel, libid3lib-devel-static и id3lib-examples.
> >должно ли быть нечто в простой библиотеке, предназначенной только для
> >использования в других программах, что можно записать в пакет в таким именем?
> >прилагаю свой спек, с помощью которого я получаю пакеты с вышеуказанными
> >именами. сборка проходит чисто. укажите, пожалуйста, на корявости.

Если это только библиотека и в названии уже присутствует lib, префикс
lib лишний. Пример -- zlib, zlib-devel, zlib-devel-static.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Tomorrow, this will be part of the unchangeable past but fortunately,
it can still be changed today.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel