Arch packaging standards (Русский)

From ArchWiki
Revision as of 07:34, 30 December 2013 by Qubodup (Talk | contribs) (Загрузка пакетов: jason chu link update)

Jump to: navigation, search

Стандарты для создания пакетов Arch

Когда создаете пакет для Arch Linux, вы должны придерживаться стандарта по созданию пакетов Arch, который приведен ниже. Особенно если вы хотите добавить ваш пакет в Arch Linux.

Шаблон PKGBUILD

# Contributor: Ваше Имя <email собака domain точка com>

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=('i686' 'x86_64')
url="http://ADDRESS/"
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #generate with 'makepkg -g'

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr
  make || return 1
  make DESTDIR=$pkgdir install || return 1
}

Железные правила создания пакетов

  • Пакет никогда не должен инсталироваться в /usr/local
  • Когда возможно, используйте "|| return 1" в важных функциях сборки
patch -Np1 -i ../patchfile.patch || return 1
make || return 1
make DESTDIR=$startdir/pkg install || return 1
  • Не добавляйте своих переменных в ваши сборочные скрипты, возможны конфликты с переменными, используемыми в makepkg. Если невозможно этого не делать, используйте подчёркивание как префикс (_). Пример:
    _customvariable=

AUR не может определить использование ваших переменных и поэтому не может их использовать в заменах. Это часто можно наблюдать в ссылках на исходные тексты. Пример:

http://downloads.sourceforge.net/sourceforge/directxwine/$patchname.$patchver.diff.bz2

Этот недостаток сильно снижает функциональность AUR.

  • Избегайте использования /usr/libexec/. Используйте вместо этого /usr/lib/${pkgname}/
  • Поле packager из метафайла может быть изменено сборщиком с помощью соответствующей опции в файле /etc/makepkg.conf. Другой вариант - экспортировать переменную PACKAGER перед сборкой пакета с помощью makepkg:
# export PACKAGER="John Doe@your.email"
  • Все важные сообщения должны печататься в течении инсталяции. Для этого используется файл .install. Например, если пакету нужна дополнительная настройка, инструкции должны быть в этом файле.
  • Любые опциональные зависимости, которые не нужны для использования основной функциональности пакета не должны включаться в массив depends, но должны быть в массиве optdepends. В этом случае они будут напечатаны при инсталяции. Например:
 optdepends=('cups: printing support'
             'sane: scanners support'
             'libgphoto2: digital cameras support'
             'alsa-lib: sound support'
             'giflib: GIF images support'
             'libjpeg: JPEG images support'
             'libpng: PNG images support')


  • Не пишите в описании пакета имя самого пакета. Например, вместо "Nedit - это текстовый редактор для X11" лучше написать "Текстовый редактор для X11". Также постарайтесь, чтобы описание не было длинее ~80 символов.
  • Постарайтесь, чтобы длина строки в PKGBUILD не превышала ~100 символов.
  • Не делайте пустых строк в PKGBUILD
  • Общая практика - сохранять порядок следования полей в PKGBUILD, как показано выше. Однако, это не требование, только рекомендация в контексте корректного синтаксиса bash.
  • Не используйте в PKGBUILD символов национальных алфавитов. Только ASCII (Латинские буквы, цифры и знаки препинания)

Названия пакетов

  • Имя пакета должно состоять только из латинских букв и цифр; все буквы должны быть в нижнем регистре.
  • Версия пакета должна совпадать с версией автора. Версии могут включать латинские буквы если это необходимо (например версия пакета nmap = 2.54BETA32). Версия не должна содержать знак переноса! Только латинские буквы, цифры и точку.
  • Релиз пакета специфичен для пакетов Arch. Он позволяет пользователю отличать старую сборку пакета от более новой, даже если версия пакета одна и таже. Когда обновляется версия пакета, релиз пакета нужно сделать равным 1. Затем по мере улучшения/исправления пакета, очередная сборка пакета выкладывается со значением релиза, увеличенным на единицу. Когда выходит новая версия, счетчик релизов сбрасывается в единицу. Релиз пакета должен соответствовать тем же правилам, что и версия пакета.

Каталоги

  • Файлы конфигурации должны размещаться в каталоге /etc. Если таких файлов более одного можно использовать подкаталог чтобы не забивать /etc. Используйте имя /etc/{pkgname}/ для подкаталога, где {pkgname} это имя вашего пакета (или разумная альтернатива, т.е. пакет apache использует /etc/httpd/).
  • Файлы пакета должны соответствовать требованиям, приведенным ниже.

Общие правила для каталогов:

/etc Общесистемные файлы настроек
/usr/bin Исполняемые файлы
/usr/sbin Исполняемые файлы для пользователя root
/usr/lib Библиотеки
/usr/include Заголовочные файлы для програм на C
/usr/lib/{pkg} Модули, плагины, расширения и т.д.
/usr/share/man man-страницы
/usr/share/{pkg} Архитектурнонезависимые данные приложения
/etc/{pkg} Файлы настроек пакета {pkg}
/opt Огромные приложения "замкнутые в себе", такие как KDE, Mozilla, Gnome и т.д.
  • Пакет не должен содержать нижепреведенных директорий:
    • /dev
    • /home
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp

Обязанности makepkg

Когда вы запускаете команду makepkg для сборки пакета, она делает следующие вещи автоматически:

  1. Проверяет установлены ли зависимости
  2. Скачивает исходные файлы из Интернета
  3. Распаковывает те архивы, которые может (tar.gz, tar.bz2, zip...)
  4. Вносит необходимые исправления
  5. Собирает программу и устанавливает ее в fake root
  6. Удаляет /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info из пакета
  7. Удаляет' все символы из исполняемых файлов
  8. Удаляет' отладочные символы из библиотек
  9. Создает метафайлы пакета, которые впоследствии будут в него включены
  10. Упаковывает содержимое fake root в пакет
  11. Сохраняет пакет в указанном каталоге (по умолчанию в текущем каталоге)

Лицензия

Пакет с лицензиями есть в репозитории current. Вы можете его использовать следующим образом:

  • Пакет current/licenses содержит некоторое количество частоиспользуемых лицензий в директории /usr/share/licenses/common. Например, /usr/share/licenses/common/GPL. Если ваш пакет имеет одну из этих лицензий, переменная licenses должна быть установлена в PKGBUILD, например, license=("GPL")
  • Если подходящей лицензии нет, можно сделать несколько вещей:
  1. Добавить в пакет директорию /usr/share/licenses/$pkgname/ с лицензией. Например /usr/share/licenses/dibfoo/COPYING.
  2. Если исходные тексты не содержат лицензии, скопируйте ее в сайта автора.
  3. Присвойте значение 'custom' переменной license. Также можно вместо 'custom' написать 'custom:"имя-лицензии"'.
  • Если лицензия используется более чем одним пакетом из официальных репозитариев и [community], она добавляется в папку common.
  • Лицензии MIT, BSD и Python - отдельный случай. Они не могут быть включены в пакет с общими лицензиями. Для переменной license - это выглядит как общие лицензии (license=("BSD"), license=("MIT") или license=("Python")), но со стороны файловой системы это custom лицензия, потому что каждый пакет имеет свою собственную строку с копирайтом. Каждый пакет с лицензиями MIT, BSD или Python должен содержать свою копию лицензии в /usr/share/licenses/$pkgname/.
  • Некоторые пакеты не могут использовать одну лицензию. В таких случаях переменная license содержит массив, т.е. license=("GPL" "custom:some commercial license"). Для большинства пакетов эти лицензии применяются в разных случаях использования пакета. Когда pacman получит возможность фильтровать пакеты по лицензии (т.е. вы сможете сказать "Я хочу использовать только программы, лицензированные под GPL или BSD") две и более лицензии скорее всего будут обрабатываться используя операцию ИЛИ, а не операцию И, т.е. pacman будет рассматривать приведенный пример как ПО под GPL, а не под какой-то другой лицензией.

Загрузка пакетов

Перед загрузкой пакетов убедитесь, что:

  • Присутствует корректное поле md5sum, которое может быть сгенерировано при помощи makepkg -g.
  • Добавлен коментарий в первой строке PKGBUILD в таком формате:
# Contributor: Ваше Имя <ваш.e-mail>
  • Все зависимости поставлены корректно (например, запустите ldd на выполняемых файлах чтобы узнать от чего они зависят...).

Команда доверенных пользователей настоятельно рекомендует использовать программу namcap, написанную Jason Chu, для проверки ваших пакетов. namcap расскажет вам о неверных правах доступа, зависимостях и других общих ошибках. Вы можете установить namcap с помощью pacman.

Помните, что namcap может проверять не только собраные пакеты pkg.tar.gz, но и PKGBUILD'ы.

  • Зависимости - наиболее общая ошибка. Namcap может помочь в исправлении, но не всегда корректно. Проверьте зависимости еще раз, глядя в исходные тексты, документацию и на сайт автора.
  • Не используйте replaces в вашем PKGBUILD если только вы не хотите переименовать пакет. Например Ethereal переименовался в Wireshark. Если вы просто сделали альтернативную версию уже существующего пакета, используйте conflictsprovides если этот пакет используется в зависимостях других пакетов). Главное отличие в том, что после синхронизации (-Sy) pacman заменить установленные пакеты, 'предлагая' пакеты с подходящими полями replaces во всех репозиториях; conflicts напротив, обрабатывается только непосредственно при установке пакета.
  • Все файлы загружаемые в AUR должны быть упакованы в tar.gz, который содержит каталог в PKGBUILD и дополнительные файлы для сборки (патчи, .install-файл, ...).
foo/PKGBUILD
foo/foo.install
foo/foo_bar.diff
foo/foo.rc.conf

Имя архива должно совпадать с именем пакета т.е. foo.tar.gz

Архив не должен содержать ни бинарный пакет, созданный makepkg, ни список файлов (filelist)

Дополнительные советы

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

CVS/SVN Packages

Смотрите страницу Arch CVS & SVN PKGBUILD guidelines

Gnome Packages

Смотрите страницу Gnome package guidelines

Haskell Packages

Смотрите страницу Haskell package guidelines

Java Packages

Смотрите страницу Java Package Guidelines

Lisp Packages

Смотрите страницу Lisp Package Guidelines

Perl Packages

Смотрите страницу Perl Package Guidelines

Ruby Gem Packages

Смотрите страницу Ruby Gem Package Guidelines

Wine Packages

Смотрите страницу Arch wine PKGBUILD guidelines

Kernel Module Packages

Смотрите страницу Kernel Module Package Guidelines