From ArchWiki

i18n
English
Русский
Español
繁體中文

Contents 1 Стандарты для создания пакетов Arch 1.1 Шаблон PKGBUILD 1.2 Железные правила создания пакетов 1.3 Названия пакетов 1.4 Каталоги 1.5 Обязанности makepkg 1.5.1 "Этикет" пакетов 1.6 Лизенция 1.7 Загрузка пакетов 2 Дополнительные советы 2.1 CVS/SVN пакеты 2.2 Java пакеты

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

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

[edit] Шаблон PKGBUILD

# Contributor: Your Name <youremail@domain.com>
pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
depends=()
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
groups=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=(generate with makepkg -g)

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

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

• Пакет никогда не должен инсталироваться в /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. Например, если пакету нужна дополнительная настройка, инструкции должны быть в этом файле.

• Любые опциональные зависимости, которые не нужны для использования основной функциональности пакета не должны включаться, но должны быть соответствующие предупреждения в файле .install, они будут напечатаны при инсталяции. Например: "To enable SMB support, download the Samba package."

• Не пишите в описании пакета имя самого пакета. Например, вместо "Nedit - это текстовый редактор для X11" лучше написать "Текстовый редактор для X11". Также постарайтесь, чтобы описание не было длинее ~80 символов.

• Постарайтесь, чтобы длина строки в PKGBUILD не превышала ~100 символов.

• Не делайте пустых строк в PKGBUILD

• Общая практика - сохранять порядок следования полей в PKGBUILD, как показано выше. Однако, это не требование, только рекомендация в контексте корректного синтаксиса bash.

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

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

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

• Релиз пакета специфичен для пакетов Arch. Он позволяет пользователю отличать старую сборку пакета от более новой, даже если версия пакета одна и таже. Когда обновляется версия пакета, релиз пакета нужно сделать равным 1. Затем по мере улучшения/исправления пакета, очередная сборка пакета выкладывается со значением релиза, увеличенным на единицу. Когда выходит новая версия, счетчик релизов сбрасывается в единицу. Релиз пакета должен соответствовать тем же правилам, что и версия пакета.

[edit] Каталоги

• Файлы конфигурации должны размещаться в каталоге /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

[edit] Обязанности 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. Сохраняет пакет в указанном каталоге (по умолчанию в текущем каталоге)

[edit] "Этикет" пакетов

• Пакеты не должны устанавливать файлы в /usr/local

• Не вводите новые переменные в вашем PKGBUILD скрипте, за исключением случаев, когда пакет не может быть собран без них, т.к. они могут конфликтовать с переменными которые использует makepkg.

Если новая переменная действительно необходима, добавьте перед именем переменной подчеркивание (_) Например

_customvariable=

AUR не может отслеживать использование собственных переменных и не может их подставлять. Наиболее часто это можно встретить в массиве sources, например:

http://dl.sourceforge.net/sourceforge/directxwine/$_patchname.$_patchver.diff.bz2

Имена переменных не будут заменены на значения в веб-интерфейсе.

• Не используйте католог /usr/libexec/. Используйте /usr/lib/{pkg} вместо него.

• Поле packager в метаинформации пакета может быть изменено в файле /etc/makepkg.conf, или установкой переменной окружения PACKAGER перед сборкой пакета командой makepkg:

  # export PACKAGER="John Doe@your.email"

• Все важные для установки замечания должны быть напечатаны при помощи .install файла. Например, если пакет требует дополнительных действий после установки для нормальной работы, инструкция должна быть включена в .install файл.

• Не обязательные зависимости, которые не нужны для запуска программы не должны включаться в поле depends. Однако следует напечатать соответствующее уведомление при помощи .install файла. Например: "To enable SMB support, download the Samba package." ("Если вы хотите использовать SMB протокол, установите пакет samba")

• При заполнении поля описание пакета не включайте имя пакета. Например: "Nedit is a text editor for X11" может быть сокращено до "A text editor for X11". Также старайтесь уместить описание в ~80 символов или меньше.

• Старайтесь придерживаться длины строки в PKGBUILD менее ~100 символов.

• Не используйте в PKGBUILD символов национальных алфавитов. Только ASCII (Латинские буквы, цифры и знаки препинания)

[edit] Лизенция

Пакет с лицензиями есть в репозитории 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, а не под какой-то другой лицензией.

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

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

• Присутствует корректное поле md5sum, которое может быть сгенерировано при помощи makepkg -g.

• Добавлен коментарий в первой строке PKGBUILD в таком формате:

# Contributor: Ваше Имя <вам.e-mail>

• Все зависимости поставлены корректно (например, запустите ldd на выполняемых файлах чтобы узнать от чего они зависят...).

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

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

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

• Не используйте replaces в вашем PKGBUILD если только вы не хотите переименовать пакет. Например Ethereal переименовался в Wireshark. Если вы просто сделали альтернативную версию уже существующего пакета, используйте conflicts (и provides если этот пакет используется в зависимостях других пакетов). Главное отличие в том, что после синхронизации (-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)

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

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

[edit] CVS/SVN пакеты

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

[edit] Java пакеты

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