ALT Packaging HOWTO
Материал из ALT Linux Wiki
(ALT Packaging HOWTO перенос нормативного документа.) |
м (→Переименование пакетов: переименовал примечание) |
||
(32 промежуточные версии не показаны) | |||
Строка 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}}<br>''NB: устарели с X11R7, используем {{rpmmacro|_bindir}} и прочие без x11''</s> |
*лицензии: {{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| | + | *другие системные: {{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|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}}: отмена регистрации сервиса и его выключение при удалении. | ||
+ | |||
+ | '''Макросы, определяющие некоторые аспекты packaging policy''' | ||
+ | |||
+ | {{rpmmacro|buildroot}}: значение ''BuildRoot'' | ||
+ | |||
+ | {{rpmmacro|_defattr}}: атрибуты файлов и каталогов по умолчанию для каждой секции ''%files'' и для каждого файла, включаемого в этих секциях | ||
+ | |||
+ | {{rpmmacro|_compress_method}}: метод, используемый при сжатии документации в секции ''%install'' | ||
+ | |||
+ | {{rpmmacro|_strip_method}}: метод, используемый при обработке ELF-файлов в секции ''%install'' (макрос удален с версии rpm-4.0.4-alt100.36) | ||
+ | |||
+ | {{rpmmacro|findreq_default_method}}: метод, используемый по умолчанию при поиске требуемых зависимостей | ||
+ | |||
+ | {{rpmmacro|findprov_default_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|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) | ||
+ | |||
+ | {{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 (макрос удален с версии rpm-4.0.4-alt100.36) | ||
+ | |||
+ | {{rpmmacro|cleanup_build}}: вызов ''/usr/lib/rpm/brp-cleanup'' | ||
+ | |||
+ | {{rpmmacro|compress_docs}}: вызов ''/usr/lib/rpm/brp-compress'' | ||
+ | |||
+ | {{rpmmacro|strip_binaries}}: вызов ''/usr/lib/rpm/brp-strip'' (макрос удален с версии rpm-4.0.4-alt100.36) | ||
+ | |||
+ | {{rpmmacro|clean_buildroot}}: выполнение ''rm -rf %buildroot'', если ''%buildroot'' не указывает на настоящий ''/''. | ||
+ | |||
+ | '''Управление процессом сборки''' | ||
+ | |||
+ | {{rpmmacro|buildmulti}}: Альтернативная директива ''%build'' для случая, когда в секции ''%build'' происходит заполнение ''%buildroot''. Вообще говоря, такой техники стоит избегать во всех случаях, когда это возможно. | ||
+ | |||
+ | '''Версии некоторых установленных в системе пакетов''' | ||
+ | |||
+ | '''glibc''': {{rpmmacro|__glibc_version}}, {{rpmmacro|__glibc_version_major}}, {{rpmmacro|__glibc_version_minor}} | ||
+ | |||
+ | '''python''': {{rpmmacro|__python_version}} | ||
+ | |||
+ | {{rpmmacro|get_version}}: Версия указанного пакета | ||
+ | |||
+ | {{rpmmacro|get_release}}: Релиз указанного пакета | ||
+ | |||
+ | {{rpmmacro|get_serial}}: Serial указанного пакета | ||
+ | |||
+ | {{rpmmacro|add_serial}}: Serial указанного пакета в виде, пригодном для включения в ''spec''-файл. | ||
Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать. | Эти макросы, как правило, используются в пакетах, сборка которых возможна с различными версиями этих программ, если эти версии правильно учитывать. | ||
- | '''Прочие макросы | + | '''Прочие макросы''' |
- | + | {{rpmmacro|intel}}: список архитектур ''intel'', совместимых с ''i386'' | |
- | + | ||
- | + | {{rpmmacro|amd}}: список архитектур ''amd'', совместимых с ''i386'' | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | {{rpmmacro|ix86}}: список всех архитектур, совместимых с ''i386'' | |
+ | |||
+ | компоненты макроса {{rpmmacro|packager}}: {{rpmmacro|packagerName}}, {{rpmmacro|packagerAddress}}. | ||
- | + | ==== Новыe параметры rpm ==== | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | -'''bE''': новый режим работы ''rpm'', при котором происходит только подстановка макросов | |
- | ''' | + | -'''nowait-lock''': не блокировать процесс, если база данных ''rpm'' занята |
- | + | ||
- | ''' | + | -'''fancypercent''': отображать дополнительную информацию о процентах проделанной работы при установке/обновлении пакетов. |
- | + | ||
- | + | ==== Новые возможности rpm ==== | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | '''Автоматический поиск требуемых и предоставляемых зависимостей''' | |
- | ''' | + | В дополнение к стандартному поиску зависимостей от/для разделяемых библиотек, реализована поддержка поиска требуемых зависимостей для ''shell'' и ''perl''-скриптов, а также поддержка поиска предоставляемых зависимостей для ''perl''-скриптов. |
- | + | ||
- | + | '''Изменение семантики тэгов, управляющих поиском зависимостей''' | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Новые возможности ''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'', что на практике означает использование макросов | |
- | + | {{rpmmacro|findreq_default_method}} и {{rpmmacro|findprov_default_method}} для определения методов поиска зависимостей. | |
- | + | ||
- | + | ||
- | + | '''Автоматическое сжатие ''man'' и ''info''-документации с поддержкой различных методов сжатия''' | |
- | ''' | + | Вся документация пакета, распознаваемая как ''man'' или ''info''-документация, по окончании работы секции ''%install'', сжимается согласно выбранному методу. Поддерживаются следующие методы сжатия: |
- | + | ||
- | ''' | + | *''bzip2'': сжатие с помощью ''bzip2 -9'' |
- | + | *''gzip'': сжатие с помощью ''gzip -9n'' | |
+ | *''auto'': сжатие с помощью ''gzip -9n'' либо ''bzip2 -9'' в зависимости от того, какой вариант окажется эффективнее | ||
+ | *''none'': производится декомпрессия файлов вместо сжатия | ||
+ | *''skip'': процедура сжатия пропускается полностью. | ||
- | '''Автоматическая | + | Какой метод будет использован в каждом конкретном случае, зависит от значения макроса {{rpmmacro|_compress_method}}; значение по умолчанию для этого макроса - ''auto''. По окончании процедуры сжатия производится выравнивание ссылок, которые, возможно, требуют коррекции в связи с изменениями имен файлов в процессе их сжатия. |
- | Перед выполнением секции %install и по окончании выполнения секции %clean rpm автоматически очищает BuildRoot с помощью макроса | + | |
+ | '''Автоматическое удаление отладочной информации из 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}}, которое есть набор из следующих возможных значений: | ||
+ | |||
+ | *''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 было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным. | Ранее в начале каждой секции %files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью довольно однообразно используемой директивы %defattr. Теперь это происходит автоматически в начале каждой секции %files, а также в начале каждого файла, включаемого в секцию %files с помощью опции -f. Точнее говоря, в качестве этой директивы используется значение макроса %_defattr. Таким образом, прежнее использование директивы %defattr в начале секций и файлов следует считать упраздненным. | ||
- | '''Сборка пакетов привилегированным пользователем | + | '''Сборка пакетов привилегированным пользователем''' |
- | + | ||
- | === Пожелания packager'у | + | То, что когда-то было необходимостью, со временем стало излишним, а порой и просто опасным. Теперь, когда все пакеты, кроме одного-единственного MAKEDEV, можно (и нужно) собирать непривилегированным пользователем во избежание риска разрушения системы и некорректной сборки, сборка пакетов привилегированным пользователем по умолчанию запрещена. Этот запрет можно снять путем изменения значения макроса {{rpmmacro|_allow_root_build}}. |
- | ==== Устаревшие конструкции | + | |
- | Не следует использовать устаревшие конструкции - они лишь загромождают spec-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся: | + | === Пожелания packager'у === |
- | тэг BuildRoot:; | + | |
- | cтроки вида rm -rf $RPM_BUILD_ROOT; | + | ==== Устаревшие конструкции ==== |
- | + | ||
- | секция %clean, пустая либо без разумного содержания. | + | Не следует использовать устаревшие конструкции - они лишь загромождают ''spec''-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся: |
+ | * тэг ''BuildRoot:'' (BuildRoot выбирается автоматически); | ||
+ | * cтроки вида ''rm -rf $RPM_BUILD_ROOT'' (BuildRoot очищается автоматически); | ||
+ | * {{rpmmacro|_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 | ||
+ | *Serial | ||
+ | |||
+ | далее | ||
+ | |||
+ | *Summary | ||
+ | *License | ||
+ | *Group | ||
+ | *Url | ||
+ | *Packager | ||
+ | *BuildArch | ||
+ | |||
+ | потом | ||
+ | |||
+ | *Source | ||
+ | *Patch | ||
+ | |||
+ | далее | ||
+ | |||
+ | *Provides | ||
+ | *Requires | ||
+ | *PreReqs | ||
+ | *Conflicts | ||
+ | и, наконец, | ||
+ | |||
+ | *Prefix | ||
+ | *BuildPreReqs | ||
+ | *BuildRequires. | ||
+ | |||
+ | Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что ''BuildRequires'' зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать ''BuildPreReq''. | ||
+ | |||
+ | ==== Файлы локализации ==== | ||
+ | |||
+ | Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос {{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'' либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях. | ||
+ | |||
+ | ==== Статические библиотеки ==== | ||
+ | |||
+ | Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя ''devel''-подпакета заканчивается суффиксом ''-devel'', то имя нового ''devel-static''-подпакета будет заканчиваться суффиксом ''-devel-static''. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей ''devel-static''-подпакета должна присутствовать зависимость от ''-devel = %version-%release''. | ||
+ | |||
+ | ==== Переименование пакетов ==== | ||
+ | |||
+ | Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать: | ||
+ | тэг ''Provides: старое_имя = %version'' | ||
+ | тэг ''Obsoletes: старое_имя'' | ||
+ | |||
+ | (Примечание: [[Реагирует ли сборочница на переименование пакетов]].) | ||
+ | |||
+ | ==== Наименование патчей ==== | ||
+ | |||
+ | При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: 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 - патчи, исправляющие ошибки, найденные компилятором. | |
- | + | ||
- | + | == Литература == | |
- | + | ||
- | Список рассылки для разработчиков rpm: rpm- | + | *[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. (снэпшот книги) | ||
- | + | == Примечания == | |
+ | * исходная версия этого документа доступна [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}}}} |
Текущая версия на 13:24, 5 ноября 2016
ALT Packaging HOWTO (revision 0.3)
Dmitry V. Levin <ldv@altlinux.ru> ALT Linux Team
Введение
При разработке изменений и дополнений к rpm решались следующие задачи:
- Обеспечить желаемую функциональность:
наши пакеты должны отвечать определенным правилам, о которых пойдет речь несколько позже. Для этого надо, чтобы spec-файлы обеспечивали выполнение этих правил.
- Помочь разработчику:
так как spec-файлы все еще пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных spec-файлах более одного раза, то надо написать макрос(ы).
- Сделать spec-файлы более читабельными:
те, кто эти файлы читает - тоже живые люди. Им будет удобнее, если в наименовании, расположении и использовании различных элементов spec-файлов будет определенный порядок.
Особенности этой версии rpm
Новые макросы
Макросы для часто используемых каталогов
X11R6: %_x11dir, %_x11bindir, %_x11libdir, %_x11includedir, %_x11mandir, %_x11datadir
NB: устарели с X11R7, используем %_bindir и прочие без x11
- лицензии: %_licensedir
- меню:
%_menudir, %_iconsdir, %_miconsdir, %_liconsdir
- emacs: %_emacslispdir
- другие системные: %_initddir (%_initir и %_initrddir объявлены устаревшими), %_lockdir, %_logdir.
Управление опциями компилятора 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, 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 выбирается автоматически);
- 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
- Serial
далее
- Summary
- License
- Group
- Url
- Packager
- BuildArch
потом
- Source
- Patch
далее
- Provides
- Requires
- PreReqs
- Conflicts
и, наконец,
- Prefix
- BuildPreReqs
- BuildRequires.
Разумеется, не все из вышеперечисленных тэгов, как правило, используются, равно как встречаются и другие редко используемые тэги. В связи с тем, что BuildRequires зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать BuildPreReq.
Файлы локализации
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, стоит использовать макрос %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 либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.
Статические библиотеки
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя devel-подпакета заканчивается суффиксом -devel, то имя нового devel-static-подпакета будет заканчиваться суффиксом -devel-static. При разделении подпакетов следует помнить о внутрипакетных зависимостях: В списке зависимостей devel-static-подпакета должна присутствовать зависимость от -devel = %version-%release.
Переименование пакетов
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:
тэг Provides: старое_имя = %version тэг Obsoletes: старое_имя
(Примечание: Реагирует ли сборочница на переименование пакетов.)
Наименование патчей
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: 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 - патчи, исправляющие ошибки, найденные компилятором.
Литература
- Официальный web-сайт rpm
- Список рассылки для разработчиков rpm 4.x
- Maximum RPM, Edward C. Bailey February 17, 1997. (снэпшот книги)
Примечания
- исходная версия этого документа доступна здесь или в документации Master 2.4
- ↑ НИКОГДА не используйте %post_service для
перезапуска сторонних сервисов. (raorn@)
/sbin/service %apache2_dname condreload|condrestart ||:
- ↑ %post_service предназначен для
- регистрации сервиса при первой установке пакета;
- перезапуске сервиса при обновлении пакета.
- ↑ http://lists.altlinux.org/pipermail/devel/2011-January/187944.html
- ↑ http://lists.altlinux.org/pipermail/devel/2011-February/188021.html