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

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


Строка 8: Строка 11:
При разработке изменений и дополнений к rpm решались следующие задачи:
При разработке изменений и дополнений к rpm решались следующие задачи:
*Обеспечить желаемую функциональность:
*Обеспечить желаемую функциональность:
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы spec-файлы обеспечивали выполнение этих правил.  
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы ''spec''-файлы обеспечивали выполнение этих правил.  
*Помочь разработчику:
*Помочь разработчику:
так как spec-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных spec-файлах более одного раза, то надо написать макрос(ы).  
так как ''spec''-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных ''spec''-файлах более одного раза, то надо написать макрос(ы).  
*Сделать spec-файлы более читабельными:
*Сделать ''spec''-файлы более читабельными:
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов spec-файлов будет определенный порядок.  
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов ''spec''-файлов будет определенный порядок.  


=== Особенности этой версии rpm ===
=== Особенности этой версии rpm ===
Строка 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'''
 
{{rpmmacro|add_optflags}} <options>: добавить указанные параметры в стандартный набор {{rpmmacro|_%opflags}}
 
{{rpmmacro|remove_optflags}} <options>: убрать указанные параметры из стандартного набора {{rpmmacro|_%opflags}}
 
{{rpmmacro|optflags_core}}: базовые параметры
 
{{rpmmacro|__optlevel}}: уровень оптимизации
{{rpmmacro|optflags_optimization}}: параметры, отвечающие за оптимизацию, кроме архитектурно-зависимых
 
{{rpmmacro|optflags_warnings}}: ''warning options''
 
{{rpmmacro|optflags_debug}}: ''debugging options''
 
{{rpmmacro|optflags_shared}}: параметры, применяемые для создания relocatable файлов
 
{{rpmmacro|optflags_nocpp}}: параметры, отключающие поддержку C++ exceptions и C++ RTTI
 
{{rpmmacro|optflags_notraceback}}: ''-fomit-frame-pointer''
{{rpmmacro|optflags_fastmath}}: ''-ffast-math''
 
{{rpmmacro|optflags_strict}}: ''-fstrict-aliasing''
 
{{rpmmacro|optflags_kernel}}: параметры, используемые при компиляции ядра и его модулей.
 
По умолчанию, стандартный набор {{rpmmacro|optflags}} состоит из "{{rpmmacro|optflags_core}} {{rpmmacro|optflags_warnings}} {{rpmmacro|optflags_optimization}}".
 
'''Макросы-надстройки над утилитой make'''
 
{{rpmmacro|make_build}}: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде
{{rpmmacro|make_install}}: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefile'ов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;
{{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>
 
<s>{{rpmmacro|uninstall_info}}: отмена регистрации удаленных ''info''-страниц.</s>
 
''Устарело с появлением filetriggers''
 
<s>'''Регистрация меню'''</s>
 
<s>{{rpmmacro|update_menus}}: регистрация новых/обновленных меню.</s>
 
<s>{{rpmmacro|clean_menus}}: отмена регистрации удаленных меню.</s>
 
''Устарело с появлением filetriggers''
 
'''Вспомогательные макросы %configure'''
 
{{rpmmacro|__libtoolize}}: путь к скрипту ''libtoolize''
 
{{rpmmacro|_configure_script}}: путь к скрипту ''configure''
 
{{rpmmacro|_configure_target}}: целевая платформа для ''configure''
{{rpmmacro|_configure_gettext}}: ''-without-included-gettext''.
 
'''Серверные макросы'''
 
{{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}}: отмена регистрации сервиса и его выключение при удалении.  


'''Управление опциями компилятора gcc.'''
'''Макросы, определяющие некоторые аспекты packaging policy'''
 
{{rpmmacro|buildroot}}: значение ''BuildRoot''
{{rpmmacro|_defattr}}: атрибуты файлов и каталогов по умолчанию для каждой секции ''%files'' и для каждого файла, включаемого в этих секциях


%add_optflags <options>: добавить указанные параметры в стандартный набор %opflags;
{{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install''
%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: параметры, используемые при компиляции ядра и его модулей.


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


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


%make_build: вызов make с параметром, обеспечивающим оптимальную параллельную сборку в данной среде;
{{rpmmacro|set_strip_method}}: изменить значение макроса ''%_strip_method'' (макрос удален с версии rpm-4.0.4-alt100.36, вместо него с параметром ''none'' пользуйтесь {{rpmmacro|brp_strip_none}})
%make_install: вызов make c инициализацией переменной INSTALL, что в случае корректной реализации Makefileов пакета позволяет сохранить дату последней модификации файлов, что особенно важно для документации;
%makeinstall:``%make_install <инициализация других переменных, используемых многими Makefileами> install''.


'''Регистрация документации в формате info.'''
'''Вызов вспомогательных программ'''


%install_info: регистрация новых/обновленных info-страниц;
{{rpmmacro|find_lang}}: вызов ''/usr/lib/rpm/find-lang''
%uninstall_info: отмена регистрации удаленных info-страниц.  
{{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  (макрос удален с версии rpm-4.0.4-alt100.36)


%update_menus: регистрация новых/обновленных меню;
{{rpmmacro|strip_shared}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF shared objects (макрос удален с версии rpm-4.0.4-alt100.36)
%clean_menus: отмена регистрации удаленных меню.  
{{rpmmacro|strip_static}}: вызов ''/usr/lib/rpm/brp-strip'' для обработки ELF ar archives (макрос удален с версии rpm-4.0.4-alt100.36)


'''Вспомогательные макросы %configure.'''
{{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup''


%__libtoolize: путь к скрипту libtoolize;
{{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress''
%_configure_script: путь к скрипту configure;
%_configure_target: целевая платформа для configure;
%_configure_gettext: -without-included-gettext.


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


%post_service: регистрация нового сервиса при установке, перезапуск при обновлении;
{{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''.  
%preun_service: отмена регистрации сервиса и его выключение при удалении.  


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


%buildroot:
{{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно.
    значение BuildRoot;
%_defattr:
    атрибуты файлов и каталогов по умолчанию для каждой секции %files и для каждого файла, включаемого в этих секциях;
%_compress_method:
    метод, используемый при сжатии документации в секции %install;
%_strip_method:
    метод, используемый при обработке ELF-файлов в секции %install;
%_findreq_default_method:
    метод, используемый по умолчанию при поиске требуемых зависимостей;
%_findprov_default_method:
    метод, используемый по умолчанию при поиске предоставляемых зависимостей;
%set_strip_method:
    изменить значение макроса %_strip_method;


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


%find_lang:
'''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}}
    вызов /usr/lib/rpm/find-lang
%strip_executable:
    вызов /usr/lib/rpm/brp-strip для обработки ELF executables;
%strip_relocatable:
    вызов /usr/lib/rpm/brp-strip для обработки ELF relocatables;
%strip_shared:
    вызов /usr/lib/rpm/brp-strip для обработки ELF shared objects;
%strip_static:
    вызов /usr/lib/rpm/brp-strip для обработки ELF ar archives;
%cleanup_build:
    вызов /usr/lib/rpm/brp-cleanup;
%compress_docs:
    вызов /usr/lib/rpm/brp-compress;
%strip_binaries:
    вызов /usr/lib/rpm/brp-strip;
%clean_buildroot:
    выполнение rm -rf %buildroot, если %buildroot не указывает на настоящий /.


'''Управление процессом сборки.'''
'''python''': {{rpmmacro|__python_version}}


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


'''Версии некоторых установленных в системе пакетов.'''
{{rpmmacro|get_release}}: Релиз указанного пакета
{{rpmmacro|get_serial}}: Serial указанного пакета


glibc:
{{rpmmacro|add_serial}}: Serial указанного пакета в виде, пригодном для включения в ''spec''-файл.  
    %__glibc_version, %__glibc_version_major, %__glibc_version_minor;
python:
    %__python_version;
%get_version:
    Версия указанного пакета;
%get_release:
    Релиз указанного пакета;
%get_serial:
    Serial указанного пакета;
%add_serial:
    Serial указанного пакета в виде, пригодном для включения в spec-файл.  


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


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


%intel:
==== Новыe параметры rpm ====
    список архитектур intel, совместимых с i386;
%amd:
    список архитектур amd, совместимых с i386;
%ix86:
    список всех архитектур, совместимых с i386;
компоненты макроса %packager:
    %packagerName, %packagerAddress.


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


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


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


'''Автоматический поиск требуемых и предоставляемых зависимостей.'''
==== Новые возможности rpm ====
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для shell и perl-скриптов, а также поддержка поиска предоставляемых зависимостей для perl-скриптов.


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


    * lib: включение поиска зависимостей от/для разделяемых библиотек;
В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. (См. также [[rpm/AutoReq]].)
    * 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-документации с поддержкой различных методов сжатия.'''
Новые возможности ''rpm'' по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов ''AutoReq'', ''AutoProv'' и ''AutoReqProv''. К стандартным значениям ''yes/no'' (''true/false''), таким образом, добавлены новые возможные значения, являющиеся именами методов поиска зависимостей:
Вся документация пакета, распознаваемая как man или info-документация, по окончании работы секции %install, сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:


    * bzip2: сжатие с помощью ``bzip2 -9'';
*''lib'': включение поиска зависимостей от/для разделяемых библиотек
    * gzip: сжатие с помощью ``gzip -9n'';
*''shell'': включение поиска зависимостей в ''shell''-скриптах
    * auto: сжатие с помощью ``gzip -9n'' либо ``bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее;
*''perl'': включение поиска зависимостей в ''perl''-скриптах
    * none: производится декомпрессия файлов вместо сжатия;
*''nolib'': выключение поиска зависимостей от/для разделяемых библиотек
    * skip: процедура сжатия пропускается полностью.
*''noshell'': выключение поиска зависимостей в ''shell''-скриптах
*''noperl'': выключение поиска зависимостей в ''perl''-скриптах
*''default'': то же, что и ''yes'';
*''none,off'': то же, что и ''no'';
*''all'': включение всех возможных методов поиска зависимостей.


Какой метод будет использован в каждом конкретном случае, зависит от значения макроса %_compress_method; значение по умолчанию для этого макроса - auto. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия.
Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого под пакета собираемого пакета ''AutoReq'' = ''AutoProv'' = ''yes'', что на практике означает использование макросов
{{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей.


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


    * executable: ELF executable;
Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия:
    * 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''.
*''bzip2'': сжатие с помощью ''bzip2 -9''
*''gzip'': сжатие с помощью ''gzip -9n''
*''auto'': сжатие с помощью ''gzip -9n'' либо ''bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее
*''none'': производится декомпрессия файлов вместо сжатия
*''skip'': процедура сжатия пропускается полностью.


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


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


'''Автоматическая очистка BuildRoot.'''
''Начиная с версии 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>''
Перед выполнением секции %install и по окончании выполнения секции %clean rpm автоматически очищает BuildRoot с помощью макроса %clean_buildroot. Это значит, что больше не нужно использовать эти ужасные ``rm -rf $RPM_BUILD_ROOT''. Секция %clean вообще может (и должна) быть опущена, если в ней не содержится ничего, кроме этого ``rm''. В тех редких случаях, когда в spec-файле производится заполнение BuildRoot не в секции %install, как это должно быть, а в секции %build, что в принципе неправильно, можно перенести точку очистки BuildRoot из начала секции %install в начало секции %build, если заменить директиву %build на макрос %buildmulti.
 
Зачастую возможно уменьшить размер получаемых в результате сборки пакета ELF-файлов без потери качества за счет удаления из них отладочной информации. Поэтому по окончании работы секции ''%install'' все ELF-файлы выбранных типов обрабатываются программой ''strip''. Выбор типов файлов определяется значением макроса {{rpmmacro|_strip_method}}, которое есть набор из следующих возможных значений:
 
*''executable'': ELF executable;
*''relocatable'': ELF relocatable;
*''shared'': ELF shared object;
*''static'': ar archive.
 
Кроме того, есть возможность вызывать ''strip'' вручную, для этой цели предназначены макросы {{rpmmacro|strip_executable}}, {{rpmmacro|strip_relocatable}}, {{rpmmacro|strip_shared}}, {{rpmmacro|strip_static}}. Синтаксис этих макросов подробно изложен в ''/usr/lib/rpm/brp-strip -help''.
 
'''Автоматическая перекомпиляция python-модулей'''
 
Как известно, python-модули обычно компилируют в байтовую форму для увеличения быстродействия при последующей работе с ними. Каждый такой модуль, помимо всего прочего, хранит время своего создания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции ''%install'', непригодны, ибо не могут быть использованы после установки пакета. По этой причине теперь по окончании работы секции ''%install'' производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет использоваться программа, имя которой хранится в макросе {{rpmmacro|__python}}. Обычно это ''/usr/bin/python'', однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).
 
'''BuildRoot'''
 
Времена, когда тэг ''BuildRoot'' в ''spec''-файле определял, какой каталог ''rpm'' будет использовать в качестве ''BuildRoot'', прошли безвозвратно. Теперь этот таг не несет никакой информации и может (и должен) быть опущен. Вместо этого используется значение макроса {{rpmmacro|buildroot}}, который определен как ''%{_tmppath}/%{name}-buildroot'' в файле ''/usr/lib/rpm/macros'' и может быть переопределен в любом месте, где допускается определять макросы. В случае, если макрос {{rpmmacro|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}}.
 
'''Упрощение секции %files'''


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


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


=== Пожелания packager'у. ===
==== Фигурные скобки ====
==== Устаревшие конструкции. ====
Не следует использовать устаревшие конструкции - они лишь загромождают spec-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:
тэг BuildRoot:;
cтроки вида rm -rf $RPM_BUILD_ROOT;
%_defattr со стандартными аргументами в начале файлов и секций %files;
секция %clean, пустая либо без разумного содержания.


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


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'' могут содержать названия команд только в не изменённом виде.
 
==== Порядок тэгов ====
 
Рекомендуемый порядок заголовочных тэгов:
*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)]].
 
==== Файлы локализации ====
 
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{rpmmacro|find_lang}}. Подробная информация есть в ''/usr/lib/rpm/find-lang -h''
 
==== Группы ====
 
Следите за значением тэгов ''Group'': они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле ''/usr/lib/rpm/GROUPS''.
 
==== ChangeLog ====
{{Main|Руководство по написанию 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.


==== Порядок тэгов. ====
При составлении описания патча следует иметь в виду следующие общепринятые сокращения:
Рекомендуемый порядок заголовочных тэгов: Name, Version, Release, Serial, далее Summary, License, Group, Url, Packager, BuildArch, потом Source, Patch, далее Provides, Requires, PreReqs, Conflicts, и, наконец, Prefix, BuildPreReqs, BuildRequires. Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что BuildRequires зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать BuildPreReq.
* makefile - патчи, затрагивающие исключительно makefile*;
==== Файлы локализации. ====
* bound - проверки на границы (буфера, целых чисел, и т.п.);
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос %find_lang. Подробная информация есть в ``/usr/lib/rpm/find-lang -h''
* config - патчи, затрагивающие исключительно конфигурационные файлы;
Группы.
* configure - патчи, затрагивающие исключительно configure*;
Следите за значением тэгов Group: они должны соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле /usr/lib/rpm/GROUPS.
* doc - патчи, затрагивающие исключительно документацию;
==== Внутрипакетные зависимости. ====
* fixes - кумулятивные патчи и/или исправления по надёжности и/или безопасности;
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также верcию, релиз и serial (если есть). Например, ``Requires: %name = %version-%release''. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружен пробелами.
* format - патчи на использование форматирования строк (printf);
==== Разделяемые библиотеки. ====
* install - патчи, направленные на возможность выполнения make install непривилегированным пользователем;
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это позволит уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса ``lib`` либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.
* linux - патчи, предназначенные для портирования ПО на Linux;
==== Статические библиотеки. ====
* man - патчи, затрагивающие исключительно man-страницы;
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя devel-подпакета заканчивается суффиксом -devel, то имя нового devel-static-подпакета будет заканчиваться суффиксом -devel-static. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей devel-static-подпакета должна присутствовать зависимость от -devel = %version-%release.
* texinfo - патчи, затрагивающие исключительно документацию в формате texinfo;
Переименование пакетов.
* tmp - патчи, предназначенные для решения различных вопросов, связанных с временными файлами;
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, дожен присутствовать:
* vitmp - патчи, направленные на поддержку vitmp(1);
тэг Provides: старое_имя = %version
* warnings - патчи, исправляющие ошибки, найденные компилятором.
тэг Obsoletes: старое_имя


==== Литература ====
== Литература ==
Официальный 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