ALT Packaging HOWTO: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
 
(не показаны 42 промежуточные версии 12 участников)
Строка 1: Строка 1:
[[Категория:Devel]]
[[Категория:RPM spec]]
== ALT Packaging HOWTO (revision 0.3) ==
== ALT Packaging HOWTO (revision 0.3) ==


Строка 18: Строка 21:
==== Новые макросы ====
==== Новые макросы ====


'''Макросы для часто используемых каталогов.'''
'''Макросы для часто используемых каталогов'''


*X11R6: {{rpmmacro|_x11dir}}, {{rpmmacro|_x11bindir}}, {{rpmmacro|_x11libdir}}, {{rpmmacro|_x11includedir}}, {{rpmmacro|_x11mandir}}, {{rpmmacro|_x11datadir}}
*<s>X11R6: {{rpmmacro|_x11dir}}, {{rpmmacro|_x11bindir}}, {{rpmmacro|_x11libdir}}, {{rpmmacro|_x11includedir}}, {{rpmmacro|_x11mandir}}, {{rpmmacro|_x11datadir}}</s><br>''NB: устарели с X11R7, используем {{rpmmacro|_bindir}} и прочие без x11''
   
   
*лицензии: {{rpmmacro|_licensedir}}  
*лицензии: {{rpmmacro|_licensedir}}  


*меню: {{rpmmacro|_menudir}}, {{rpmmacro|_iconsdir}}, {{rpmmacro|_miconsdir}}, {{rpmmacro|_liconsdir}}
*меню: <s>{{rpmmacro|_menudir}}</s>, {{rpmmacro|_iconsdir}}, {{rpmmacro|_miconsdir}}, {{rpmmacro|_liconsdir}}
   
   
*emacs: {{rpmmacro|_emacslispdir}}
*emacs: {{rpmmacro|_emacslispdir}}
   
   
*другие системные: {{rpmmacro|_initdir}}, {{rpmmacro|_lockdir}}, {{rpmmacro|_logdir}}.  
*другие системные: {{rpmmacro|_initddir}} ({{rpmmacro|_initir}} и {{rpmmacro|_initrddir}} [https://bugzilla.altlinux.org/show_bug.cgi?id=24290 объявлены устаревшими]), {{rpmmacro|_lockdir}}, {{rpmmacro|_logdir}}.  


'''Управление опциями компилятора gcc.'''
'''Управление опциями компилятора gcc'''


{{rpmmacro|_add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}
{{rpmmacro|add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}


{{rpmmacro|_remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}
{{rpmmacro|remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}


{{rpmmacro|_optflags_core}}: базовые параметры
{{rpmmacro|optflags_core}}: базовые параметры


{{rpmmacro|__optlevel}}: уровень оптимизации
{{rpmmacro|__optlevel}}: уровень оптимизации
   
   
{{rpmmacro|_optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых
{{rpmmacro|optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых


{{rpmmacro|_optflags_warnings}}: ''warning options''
{{rpmmacro|optflags_warnings}}: ''warning options''


{{rpmmacro|_optflags_debug}}: ''debugging options''
{{rpmmacro|optflags_debug}}: ''debugging options''


{{rpmmacro|_optflags_shared}}: параметры, применяемые для создания relocatable файлов
{{rpmmacro|optflags_shared}}: параметры, применяемые для создания relocatable файлов


{{rpmmacro|_optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI
{{rpmmacro|optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI


{{rpmmacro|_optflags_notraceback}}: ''-fomit-frame-pointer''
{{rpmmacro|optflags_notraceback}}: ''-fomit-frame-pointer''
   
   
{{rpmmacro|_optflags_fastmath}}: ''-ffast-math''
{{rpmmacro|optflags_fastmath}}: ''-ffast-math''


{{rpmmacro|_optflags_strict}}: ''-fstrict-aliasing''
{{rpmmacro|optflags_strict}}: ''-fstrict-aliasing''


{{rpmmacro|_optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.
{{rpmmacro|optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.


По умолчанию, стандартный набор {{rpmmacro|_opflags}} состоит из "{{rpmmacro|_optflags_core}} {{rpmmacro|_optflags_warnings}} {{rpmmacro|_ptflags_optimization}}".
По умолчанию, стандартный набор {{rpmmacro|optflags}} состоит из "{{rpmmacro|optflags_core}} {{rpmmacro|optflags_warnings}} {{rpmmacro|optflags_optimization}}".


'''Макросы-надстройки над утилитой make.'''
'''Макросы-надстройки над утилитой make'''


{{rpmmacro|_make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде
{{rpmmacro|make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде
   
   
{{rpmmacro|_make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefileов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;
{{rpmmacro|make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;
   
   
{{rpmmacro|_makeinstall}}: %make_install <инициализация других переменных, используемых многими Makefileами> install''.  
{{rpmmacro|makeinstall}}: make <инициализация других переменных, используемых многими Makefile'ами> install. Переопределяет все пути, куда устанавливаются файлы, добавляя к ним buildroot (используется для неправильных установочных скриптов, в которых забыто DESTDIR);
 
{{rpmmacro|makeinstall_std}}: выполняет %make_install install DESTDIR=%buildroot, нужное для установки программы, собранной через autotools;
 
<s>'''Регистрация документации в формате info''</s>
 
<s>{{rpmmacro|install_info}}: регистрация новых/обновленных ''info''-страниц.</s>


'''Регистрация документации в формате info.'''
<s>{{rpmmacro|uninstall_info}}: отмена регистрации удаленных ''info''-страниц.</s>


{{rpmmacro|_install_info}}: регистрация новых/обновленных ''info''-страниц
''Устарело с появлением filetriggers''


{{rpmmacro|_uninstall_info}}: отмена регистрации удаленных ''info''-страниц.
<s>'''Регистрация меню'''</s>


'''Регистрация меню.'''
<s>{{rpmmacro|update_menus}}: регистрация новых/обновленных меню.</s>


{{rpmmacro|_update_menus}}: регистрация новых/обновленных меню
<s>{{rpmmacro|clean_menus}}: отмена регистрации удаленных меню.</s>


{{rpmmacro|_clean_menus}}: отмена регистрации удаленных меню.
''Устарело с появлением filetriggers''


'''Вспомогательные макросы %configure.'''
'''Вспомогательные макросы %configure'''


{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''
{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''
Строка 90: Строка 99:
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''.  
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''.  


'''Серверные макросы.'''
'''Серверные макросы'''


{{rpmmacro|_post_service}}: регистрация нового сервиса при установке, перезапуск при обновлении
{{rpmmacro|post_service}}: регистрация нового сервиса при установке, перезапуск при обновлении<ref>НИКОГДА не используйте {{rpmmacro|post_service}} для
перезапуска сторонних сервисов. ([http://lists.altlinux.org/pipermail/devel/2010-September/184624.html raorn@])<pre>/sbin/service %apache2_dname condreload|condrestart ||:</pre></ref><ref>%post_service предназначен для
* регистрации сервиса при первой установке пакета;
* перезапуске сервиса при обновлении пакета.
Запускать сервис автоматически сразу при первой установке пакета не положено. ([http://lists.altlinux.org/pipermail/devel/2010-September/184646.html ldv@])</ref>


{{rpmmacro|_preun_service}}: отмена регистрации сервиса и его выключение при удалении.  
{{rpmmacro|preun_service}}: отмена регистрации сервиса и его выключение при удалении.  


'''Макросы, определяющие некоторые аспекты packaging policy.'''
'''Макросы, определяющие некоторые аспекты packaging policy'''


{{rpmmacro|buildroot}}: значение ''BuildRoot''
{{rpmmacro|buildroot}}: значение ''BuildRoot''
Строка 104: Строка 117:
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''


{{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install''
{{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install'' (макрос удален с версии rpm-4.0.4-alt100.36)
   
   
{{rpmmacro|_findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей  
{{rpmmacro|findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей  


{{rpmmacro|_findprov_default_method}}: метод, используемый по умолчанию при поиске предоставляемых зависимостей
{{rpmmacro|findprov_default_method}}: метод, используемый по умолчанию при поиске предоставляемых зависимостей


{{rpmmacro|_set_strip_method}}: изменить значение макроса ''%_strip_method''
{{rpmmacro|set_strip_method}}: изменить значение макроса ''%_strip_method'' (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром ''none'' пользуйтесь {{rpmmacro|brp_strip_none}})


'''Вызов вспомогательных программ.'''
'''Вызов вспомогательных программ'''


{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''
{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''
   
   
{{rpmmacro|strip_executable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF executables
{{rpmmacro|strip_executable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF executables (макрос удален с версии rpm-4.0.4-alt100.36)


{{rpmmacro|strip_relocatable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF relocatables  
{{rpmmacro|strip_relocatable}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF relocatables (макрос удален с версии rpm-4.0.4-alt100.36)
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects
 
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)
   
   
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)
 
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress''  
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress''  
{{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip''
 
{{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip'' (макрос удален с версии rpm-4.0.4-alt100.36)
 
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''.  
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''.  


'''Управление процессом сборки.'''
'''Управление процессом сборки'''


{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно.  
{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно.  


'''Версии некоторых установленных в системе пакетов.'''
'''Версии некоторых установленных в системе пакетов'''


'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}}  
'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}}  
Строка 147: Строка 165:
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать.
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать.


'''Прочие макросы.'''
'''Прочие макросы'''


{{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386''
{{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386''
Строка 155: Строка 173:
{{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386''
{{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386''
   
   
компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}.  
компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}.


==== Новыe параметры rpm. ====
==== Новыe параметры rpm ====


-'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов
-'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов
Строка 165: Строка 183:
-'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов.  
-'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов.  


==== Новые возможности rpm. ====
==== Новые возможности rpm ====


'''Автоматический поиск требуемых и предоставляемых зависимостей.'''
'''Автоматический поиск требуемых и предоставляемых зависимостей'''


В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов.
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. (См. также [[rpm/AutoReq]].)


'''Изменение семантики тэгов, управляющих поиском зависимостей.'''
'''Изменение семантики тэгов, управляющих поиском зависимостей'''


Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:
Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:
Строка 188: Строка 206:
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.


'''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия.'''
'''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия'''


Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:
Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:
Строка 200: Строка 218:
Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.
Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.


'''Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке.'''
'''Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке'''
 
''Начиная с версии rpm-4.0.4-alt100.36 этот раздел устарел, brp-strip удален и вместо него используется brp-debuginfo (%_brp_strip_{debug,none}). <ref>http://lists.altlinux.org/pipermail/devel/2011-January/187944.html</ref><ref>http://lists.altlinux.org/pipermail/devel/2011-February/188021.html</ref>''


Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:
Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:
Строка 211: Строка 231:
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.


'''Автоматическая перекомпиляция python-модулей.'''
'''Автоматическая перекомпиляция python-модулей'''


Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).
Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).


'''BuildRoot.'''
'''BuildRoot'''


Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|buildroot}} не определен либо его значение представляет собой недопустимое значение ''/'', сборка пакета не будет выполнена.
Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|buildroot}} не определен либо его значение представляет собой недопустимое значение ''/'', сборка пакета не будет выполнена.


'''Автоматическая очистка BuildRoot.'''
'''Автоматическая очистка BuildRoot'''


Перед выполнением секции ''%install'' и по окончании выполнения секции ''%clean'' ''rpm'' автоматически очищает ''BuildRoot'' с помощью макроса {{rpmmacro|clean_buildroot}}. Это значит, что больше не нужно использовать эти ужасные ''rm -rf $RPM_BUILD_ROOT''. Секция ''%clean'' вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ''rm''. В тех редких случаях, когда в ''spec''-файле производится заполнение ''BuildRoot'' не в секции ''%install'', как это должно быть, а в секции ''%build'', что в принципе неправильно, можно перенести точку очистки ''BuildRoot'' из начала секции ''%install'' в начало секции ''%build'', если заменить директиву ''%build'' на макрос {{rpmmacro|buildmulti}}.
Перед выполнением секции ''%install'' и по окончании выполнения секции ''%clean'' ''rpm'' автоматически очищает ''BuildRoot'' с помощью макроса {{rpmmacro|clean_buildroot}}. Это значит, что больше не нужно использовать эти ужасные ''rm -rf $RPM_BUILD_ROOT''. Секция ''%clean'' вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ''rm''. В тех редких случаях, когда в ''spec''-файле производится заполнение ''BuildRoot'' не в секции ''%install'', как это должно быть, а в секции ''%build'', что в принципе неправильно, можно перенести точку очистки ''BuildRoot'' из начала секции ''%install'' в начало секции ''%build'', если заменить директиву ''%build'' на макрос {{rpmmacro|buildmulti}}.


'''Упрощение секции %files.'''
'''Упрощение секции %files'''


Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.
Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.


'''Сборка пакетов привилегированным пользователем.'''
'''Сборка пакетов привилегированным пользователем'''


То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}.
То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}.


=== Пожелания packager'у. ===
=== Пожелания packager'у ===


==== Устаревшие конструкции. ====
==== Устаревшие конструкции ====


Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:
Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:
тэг ''BuildRoot:''
* тэг ''BuildRoot:'' (BuildRoot выбирается автоматически);
cтроки вида ''rm -rf $RPM_BUILD_ROOT''
* тэг ''Packager:'' (Packager заполняется автоматически);
{{rpmmacro|_defattr}} со стандартными аргументами в начале файлов и секций ''%files''
* cтроки вида ''rm -rf $RPM_BUILD_ROOT'' (BuildRoot очищается автоматически);
секция ''%clean'', пустая либо без разумного содержания.
* {{rpmmacro|_defattr}} со стандартными аргументами в начале файлов и секций ''%files'' (такое поведение действует по умолчанию);
* секция ''%clean'', пустая либо без разумного содержания.


==== Фигурные скобки. ====
==== Фигурные скобки ====


Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:
Строка 247: Строка 268:
''perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec''-файл
''perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec''-файл


==== Порядок тэгов. ====
Или с помощью утилиты ''cleanup_spec'' из пакета ''rpm-utils''.
 
==== Выравнивание ====
 
Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.
 
==== Значения тэгов ====
 
Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы и не следует завершать точкой. Значения тэга ''Summary'' и секции ''%description'' могут содержать названия команд только в не изменённом виде.
 
==== Порядок тэгов ====


Рекомендуемый порядок заголовочных тэгов:  
Рекомендуемый порядок заголовочных тэгов:  
Строка 253: Строка 284:
*Version
*Version
*Release
*Release
*Serial
*Epoch


далее
далее
Строка 261: Строка 292:
*Group
*Group
*Url
*Url
*Packager
*Vcs
*Packager (используется для групп сопровождения)
*BuildArch
*BuildArch


потом  
потом


*Source
*Source*
*Patch
*Patch*


далее
далее


*Provides
*Provides
*Requires(pre)
*Requires
*Requires
*PreReqs
*Conflicts
*Conflicts
*Obsoletes
и, наконец,
и, наконец,


*Prefix
*BuildRequires(pre)
*BuildPreReqs
*BuildPreReq
*BuildRequires.
*BuildRequires


Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''.
Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых с помощью [[buildreq]] зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''. ''BuildRequires(pre):'' имеет особое значение в том числе для [[hasher]]. См. также [[Spec#BuildRequires, BuildPreReq, BuildRequires(pre)]].


==== Файлы локализации. ====
==== Файлы локализации ====


Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''


==== Группы. ====
==== Группы ====


Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.
Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.


==== Внутрипакетные зависимости. ====
==== ChangeLog ====
{{Main|Руководство по написанию changelog}}
Для формирования первой строки changelog-записи удобно использовать утилиту ''[[add_changelog]]'' из пакета ''rpm-utils''.


При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ''Requires: %name = %version-%release''. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.
==== Внутрипакетные зависимости ====


==== Разделяемые библиотеки. ====
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ''Requires: %name = %version-%release'' или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.
 
==== Разделяемые библиотеки ====


Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ''lib'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ''lib'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.
Обратите внимание, что при сборке и именовании пакетов с разделяемыми библиотеками важно соблюдение [[Shared_Libs_Policy]].


==== Статические библиотеки. ====
==== Статические библиотеки ====


Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''.
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''.


==== Переименование пакетов. ====
==== Переименование пакетов ====
 
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:
тэг ''Provides: старое_имя = %EVR''
тэг ''Obsoletes: старое_имя < %EVR''
 
(Примечание: [[Реагирует ли сборочница на переименование пакетов]].)
 
==== Наименование патчей ====
 
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где
 
* NAME и VERSION  — имя и версия пакета, для которого сделан патч;
* ORIGIN  — аббревиатуры источников патча (обычно дистрибутивов);
* WHAT  — краткое описание патча.


Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, дожен присутствовать:
В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD.  
тэг ''Provides: старое_имя = %version''
тэг ''Obsoletes: старое_имя''


==== Литература ====
При составлении описания патча следует иметь в виду следующие общепринятые сокращения:
* makefile - патчи, затрагивающие исключительно makefile*;
* bound - проверки на границы (буфера, целых чисел, и т.п.);
* config - патчи, затрагивающие исключительно конфигурационные файлы;
* configure - патчи, затрагивающие исключительно configure*;
* doc - патчи, затрагивающие исключительно документацию;
* fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;
* format - патчи на использование форматирования строк (printf);
* install - патчи, направленные на возможность выполнения make install непривилегированным пользователем;
* linux - патчи, предназначенные для портирования ПО на Linux;
* man - патчи, затрагивающие исключительно man-страницы;
* texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;
* tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;
* vitmp - патчи, направленные на поддержку vitmp(1);
* warnings - патчи, исправляющие ошибки, найденные компилятором.


Официальный web-сайт rpm: http://www.rpm.org/
== Литература ==


Список рассылки для разработчиков rpm: rpm-list@redhat.com
*[http://www.rpm.org/ Официальный web-сайт rpm]
*[http://lists.rpm.org/mailman/listinfo/rpm-list Список рассылки для разработчиков rpm 4.x]
*[http://www.rpm.org/max-rpm-snapshot/index.html Maximum RPM], Edward C. Bailey  February 17, 1997. (снэпшот книги)


Edward C. Bailey ``Maximum RPM'' February 17, 1997. (доступна также online-версия по адресу http://www.rpmdp.org/rpmbook/ и в формате PostScript по адресу http://www.rpm.org/maximum-rpm.ps.gz)
== Примечания ==
* исходная версия этого документа доступна [http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/ здесь] или [http://docs.altlinux.org/archive/2.4/master/alt-docs-devel/ch04.html в документации Master 2.4]
<references />
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}

Текущая версия от 15:09, 27 апреля 2024


ALT Packaging HOWTO (revision 0.3)

Dmitry V. Levin <ldv@altlinux.ru> ALT Linux Team

Введение

При разработке изменений и дополнений к rpm решались следующие задачи:

  • Обеспечить желаемую функциональность:

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

  • Помочь разработчику:

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

  • Сделать spec-файлы более читабельными:

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

Особенности этой версии rpm

Новые макросы

Макросы для часто используемых каталогов

Управление опциями компилятора gcc

%add_optflags <options>: добавить указанные параметры в стандартный набор %_%opflags

%remove_optflags <options>: убрать указанные параметры из стандартного набора %_%opflags

%optflags_core: базовые параметры

%__optlevel: уровень оптимизации

%optflags_optimization: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых

%optflags_warnings: warning options

%optflags_debug: debugging options

%optflags_shared: параметры, применяемые для создания relocatable файлов

%optflags_nocpp: параметры, отключающие поддержку C++ exceptions и C++ RTTI

%optflags_notraceback: -fomit-frame-pointer

%optflags_fastmath: -ffast-math

%optflags_strict: -fstrict-aliasing

%optflags_kernel: параметры, используемые при компиляции ядра и его модулей.

По умолчанию, стандартный набор %optflags состоит из "%optflags_core %optflags_warnings %optflags_optimization".

Макросы-надстройки над утилитой make

%make_build: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде

%make_install: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;

%makeinstall: make <инициализация других переменных, используемых многими Makefile'ами> install. Переопределяет все пути, куда устанавливаются файлы, добавляя к ним buildroot (используется для неправильных установочных скриптов, в которых забыто DESTDIR);

%makeinstall_std: выполняет %make_install install DESTDIR=%buildroot, нужное для установки программы, собранной через autotools;

'Регистрация документации в формате info

%install_info: регистрация новых/обновленных info-страниц.

%uninstall_info: отмена регистрации удаленных info-страниц.

Устарело с появлением filetriggers

Регистрация меню

%update_menus: регистрация новых/обновленных меню.

%clean_menus: отмена регистрации удаленных меню.

Устарело с появлением filetriggers

Вспомогательные макросы %configure

%__libtoolize: путь к скрипту libtoolize

%_configure_script: путь к скрипту configure

%_configure_target: целевая платформа для configure

%_configure_gettext: -without-included-gettext.

Серверные макросы

%post_service: регистрация нового сервиса при установке, перезапуск при обновлении[1][2]

%preun_service: отмена регистрации сервиса и его выключение при удалении.

Макросы, определяющие некоторые аспекты packaging policy

%buildroot: значение BuildRoot

%_defattr: атрибуты файлов и каталогов по умолчанию для каждой секции %files и для каждого файла, включаемого в этих секциях

%_compress_method: метод, используемый при сжатии документации в секции %install

%_strip_method: метод, используемый при обработке ELF-файлов в секции %install (макрос удален с версии rpm-4.0.4-alt100.36)

%findreq_default_method: метод, используемый по умолчанию при поиске требуемых зависимостей

%findprov_default_method: метод, используемый по умолчанию при поиске предоставляемых зависимостей

%set_strip_method: изменить значение макроса %_strip_method (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром none пользуйтесь %brp_strip_none)

Вызов вспомогательных программ

%find_lang: вызов /usr/lib/rpm/find-lang

%strip_executable: вызов /usr/lib/rpm/brp-strip для обработки ELF executables (макрос удален с версии rpm-4.0.4-alt100.36)

%strip_relocatable: вызов /usr/lib/rpm/brp-strip для обработки ELF relocatables (макрос удален с версии rpm-4.0.4-alt100.36)

%strip_shared: вызов /usr/lib/rpm/brp-strip для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)

%strip_static: вызов /usr/lib/rpm/brp-strip для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)

%cleanup_build: вызов /usr/lib/rpm/brp-cleanup

%compress_docs: вызов /usr/lib/rpm/brp-compress

%strip_binaries: вызов /usr/lib/rpm/brp-strip (макрос удален с версии rpm-4.0.4-alt100.36)

%clean_buildroot: выполнение rm -rf %buildroot, если %buildroot не указывает на настоящий /.

Управление процессом сборки

%buildmulti: Альтернативная директива %build для случая, когда в секции %build происходит заполнение %buildroot. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно.

Версии некоторых установленных в системе пакетов

glibc: %__glibc_version, %__glibc_version_major, %__glibc_version_minor

python: %__python_version

%get_version: Версия указанного пакета

%get_release: Релиз указанного пакета

%get_serial: Serial указанного пакета

%add_serial: Serial указанного пакета в виде, пригодном для включения в spec-файл.

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

Прочие макросы

%intel: список архитектур intel, совместимых с i386

%amd: список архитектур amd, совместимых с i386

%ix86: список всех архитектур, совместимых с i386

компоненты макроса %packager: %packagerName, %packagerAddress.

Новыe параметры rpm

-bE: новый режим работы rpm, при котором происходит только подстановка макросов

-nowait-lock: не блокировать процесс, если база данных rpm занята

-fancypercent: отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов.

Новые возможности rpm

Автоматический поиск требуемых и предоставляемых зависимостей

В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для shell и perl-скриптов, а также поддержка поиска предоставляемых зависимостей для perl-скриптов. (См. также rpm/AutoReq.)

Изменение семантики тэгов, управляющих поиском зависимостей

Новые возможности rpm по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов AutoReq, AutoProv и AutoReqProv. К стандартным значениям yes/no (true/false), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:

  • lib: включение поиска зависимостей от/для разделяемых библиотек
  • shell: включение поиска зависимостей в shell-скриптах
  • perl: включение поиска зависимостей в perl-скриптах
  • nolib: выключение поиска зависимостей от/для разделяемых библиотек
  • noshell: выключение поиска зависимостей в shell-скриптах
  • noperl: выключение поиска зависимостей в perl-скриптах
  • default: то же, что и yes;
  • none,off: то же, что и no;
  • all: включение всех возможных методов поиска зависимостей.

Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого под пакета собираемого пакета AutoReq = AutoProv = yes, что на практике означает использование макросов %findreq_default_method и %findprov_default_method для определения методов поиска зависимостей.

Автоматическое сжатие man и info-документации с поддержкой различных методов сжатия

Вся документация пакета, распознаваемая как man или info-документация, по окончании работы секции %install, сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:

  • bzip2: сжатие с помощью bzip2 -9
  • gzip: сжатие с помощью gzip -9n
  • auto: сжатие с помощью gzip -9n либо bzip2 -9 в зависимости от того, какой вариант окажется эффективнее
  • none: производится декомпрессия файлов вместо сжатия
  • skip: процедура сжатия пропускается полностью.

Какой метод будет использован в каждом конкретном случае, зависит от значения макроса %_compress_method; значение по умолчанию для этого макроса - auto. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.

Автоматическое удаление отладочной информации из ELF-файлов с поддержкой различных стратегий выбора файлов, подлежащих обработке

Начиная с версии rpm-4.0.4-alt100.36 этот раздел устарел, brp-strip удален и вместо него используется brp-debuginfo (%_brp_strip_{debug,none}). [3][4]

Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции %install все ELF-файлы выбранных типов обрабатываются программой strip. Выбор типов файлов определяется значением макроса %_strip_method, которое есть набор из следующих возможных значений:

  • executable: ELF executable;
  • relocatable: ELF relocatable;
  • shared: ELF shared object;
  • static: ar archive.

Кроме того, есть возможность вызывать strip вручную, для этой цели предназначены макросы %strip_executable, %strip_relocatable, %strip_shared, %strip_static. Синтаксис этих макросов подробно изложен в /usr/lib/rpm/brp-strip -help.

Автоматическая перекомпиляция python-модулей

Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции %install, непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции %install производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе %__python. Обычно это /usr/bin/python, однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).

BuildRoot

Времена, когда тэг BuildRoot в spec-файле определял, какой каталог rpm будет использовать в качестве BuildRoot, прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса %buildroot, который определен как %{_tmppath}/%{name}-buildroot в файле /usr/lib/rpm/macros и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос %buildroot не определен либо его значение представляет собой недопустимое значение /, сборка пакета не будет выполнена.

Автоматическая очистка BuildRoot

Перед выполнением секции %install и по окончании выполнения секции %clean rpm автоматически очищает BuildRoot с помощью макроса %clean_buildroot. Это значит, что больше не нужно использовать эти ужасные rm -rf $RPM_BUILD_ROOT. Секция %clean вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого rm. В тех редких случаях, когда в spec-файле производится заполнение BuildRoot не в секции %install, как это должно быть, а в секции %build, что в принципе неправильно, можно перенести точку очистки BuildRoot из начала секции %install в начало секции %build, если заменить директиву %build на макрос %buildmulti.

Упрощение секции %files

Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным.

Сборка пакетов привилегированным пользователем

То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса %_allow_root_build.

Пожелания packager'у

Устаревшие конструкции

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

  • тэг BuildRoot: (BuildRoot выбирается автоматически);
  • тэг Packager: (Packager заполняется автоматически);
  • cтроки вида rm -rf $RPM_BUILD_ROOT (BuildRoot очищается автоматически);
  • %_defattr со стандартными аргументами в начале файлов и секций %files (такое поведение действует по умолчанию);
  • секция %clean, пустая либо без разумного содержания.

Фигурные скобки

Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавится от них легко:

perl -pi -e 's/%\{([A-Za-z_0-9]+)\}([^A-Za-z_0-9?*]|$)/%$1$2/g' spec-файл

Или с помощью утилиты cleanup_spec из пакета rpm-utils.

Выравнивание

Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.

Значения тэгов

Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы и не следует завершать точкой. Значения тэга Summary и секции %description могут содержать названия команд только в не изменённом виде.

Порядок тэгов

Рекомендуемый порядок заголовочных тэгов:

  • Name
  • Version
  • Release
  • Epoch

далее

  • Summary
  • License
  • Group
  • Url
  • Vcs
  • Packager (используется для групп сопровождения)
  • BuildArch

потом

  • Source*
  • Patch*

далее

  • Provides
  • Requires(pre)
  • Requires
  • Conflicts
  • Obsoletes

и, наконец,

  • BuildRequires(pre)
  • BuildPreReq
  • BuildRequires

Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что BuildRequires зарезервирован для автоматически вычисляемых с помощью buildreq зависимостей, для указания особых зависимостей следует использовать BuildPreReq. BuildRequires(pre): имеет особое значение в том числе для hasher. См. также Spec#BuildRequires, BuildPreReq, BuildRequires(pre).

Файлы локализации

Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос %find_lang. Подробная информация есть в /usr/lib/rpm/find-lang -h

Группы

Следите за значением тэгов Group: они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле /usr/lib/rpm/GROUPS.

ChangeLog

Для формирования первой строки changelog-записи удобно использовать утилиту add_changelog из пакета rpm-utils.

Внутрипакетные зависимости

При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, Requires: %name = %version-%release или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.

Разделяемые библиотеки

Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса lib либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях. Обратите внимание, что при сборке и именовании пакетов с разделяемыми библиотеками важно соблюдение Shared_Libs_Policy.

Статические библиотеки

Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя devel-подпакета заканчивается суффиксом -devel, то имя нового devel-static-подпакета будет заканчиваться суффиксом -devel-static. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей devel-static-подпакета должна присутствовать зависимость от -devel = %version-%release.

Переименование пакетов

Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:

тэг Provides: старое_имя = %EVR
тэг Obsoletes: старое_имя < %EVR 

(Примечание: Реагирует ли сборочница на переименование пакетов.)

Наименование патчей

При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где

  • NAME и VERSION — имя и версия пакета, для которого сделан патч;
  • ORIGIN — аббревиатуры источников патча (обычно дистрибутивов);
  • WHAT — краткое описание патча.

В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD.

При составлении описания патча следует иметь в виду следующие общепринятые сокращения:

  • makefile - патчи, затрагивающие исключительно makefile*;
  • bound - проверки на границы (буфера, целых чисел, и т.п.);
  • config - патчи, затрагивающие исключительно конфигурационные файлы;
  • configure - патчи, затрагивающие исключительно configure*;
  • doc - патчи, затрагивающие исключительно документацию;
  • fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;
  • format - патчи на использование форматирования строк (printf);
  • install - патчи, направленные на возможность выполнения make install непривилегированным пользователем;
  • linux - патчи, предназначенные для портирования ПО на Linux;
  • man - патчи, затрагивающие исключительно man-страницы;
  • texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;
  • tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;
  • vitmp - патчи, направленные на поддержку vitmp(1);
  • warnings - патчи, исправляющие ошибки, найденные компилятором.

Литература

Примечания

  1. НИКОГДА не используйте %post_service для перезапуска сторонних сервисов. (raorn@)
    /sbin/service %apache2_dname condreload|condrestart ||:
  2. %post_service предназначен для
    • регистрации сервиса при первой установке пакета;
    • перезапуске сервиса при обновлении пакета.
    Запускать сервис автоматически сразу при первой установке пакета не положено. (ldv@)
  3. http://lists.altlinux.org/pipermail/devel/2011-January/187944.html
  4. http://lists.altlinux.org/pipermail/devel/2011-February/188021.html