Стандарты пакетов Manjaro
Представленные PKGBUILD ни при каких обстоятельствах не должны собирать приложения, уже находящиеся в официальных бинарных репозиториях. Исключением из этого строгого правила могут быть только пакеты с включенными дополнительными функциями и/или патчами по сравнению с официальными. В этом случае массив pkgname должен быть другим.
При создании пакетов для Manjaro Linux, придерживайтесь руководства по созданию пакетов, приведенного ниже, особенно если вы собираетесь внести свой вклад в новый пакет для Manjaro Linux. Вам также следует ознакомиться с PKGBUILD и makepkg manpages.
Прототип PKGBUILD
# Maintainer: Иван Иванов <ваша_почта@домен.ru> pkgname=NAME pkgver=VERSION pkgrel=1 pkgdesc="" arch=() url="" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= changelog= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #автозаполнение с помощью updpkgsums build() { cd $pkgname-$pkgver ./configure --prefix=/usr make } package() { cd $pkgname-$pkgver make DESTDIR="$pkgdir/" install }
Другие прототипы можно найти в /usr/share/pacman
из пакетов pacman и abs.
Этикет упаковки
- Пакеты никогда не должны устанавливаться в
/usr/local
-
Не вводите новые переменные в
PKGBUILD
в скрипты сборки, если только пакет не может быть собран без этого, так как они могут конфликтовать с переменными, используемыми в самом makepkg. Если новая переменная в самом деле необходима, предварите её имя нижним подчеркиванием (_
), напр._customvariable=
AUR не может определить использование пользовательских переменных и поэтому не может использовать их в подстановках. Чаще всего это можно увидеть в исходном массиве, например.
http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2
Такая ситуация противоречит эффективной функциональности AUR.
-
Избегайте использования
/usr/libexec/
для для всего подряд. Вместо него используйте/usr/lib/${pkgname}/
. -
Поле
packager
из метафайла пакета может настраиваться создателем пакета путем изменения соответствующей опции в/etc/makepkg.conf
файл, или альтернативно переопределить его, создав ~/.makepkg.conf - Все важные сообщения должны быть озвучены во время установки с помощью файла .install. Например, например, если пакет требует дополнительной настройки для работы, следует включить указания.
- Любые необязательные зависимости, которые не нужны для запуска пакета или его общего функционирования, не должны быть включены; вместо этого информация должна быть добавлена в массив 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')
Приведенный выше пример взят для пакета wine в
extra
. Информация optdepends автоматически выводится при установке/обновлении, поэтому не следует хранить такую информацию в файлах .install. - При создании описания пакета для пакета не включайте имя пакета в виде самоссылки. Например, "Nedit is a text editor for X11" может быть упрощен до "A text editor for X11". Также старайтесь, чтобы описание не превышало ~80 символов.
- Старайтесь, чтобы длина строки в PKGBUILD не превышала ~100 символов.
- По возможности удаляйте пустые строки из
PKGBUILD
(provides
,replaces
и т.д.) - Общепринятой практикой является сохранение порядка полей
PKGBUILD
, как показано выше. Однако это необязательно, поскольку единственным требованием в данном контексте является правильный синтаксис bash.
Именование пакетов
- Имена пакетов должны состоять только из буквенно-цифровых символов; все буквы должны быть строчными.
- Имена пакетов НЕ должны иметь суффикс с номером версии основного выпуска upstream (например, нам не нужен libfoo2, если upstream называет его libfoo v2.3.4) в случае, если ожидается, что библиотека и ее зависимости будут использовать самую последнюю версию библиотеки с каждым соответствующим выпуском upstream. Однако не для всех программ или зависимостей можно ожидать подобное. В прошлом это было верно для наборов инструментов виджетов, таких как GTK и Qt. Программное обеспечение, зависящее от таких наборов инструментов, как правило не может быть тривиально перенесено на новую основную версию. Поэтому в случаях, когда программы не могут тривиально продолжать развиваться вместе со своими зависимостями, имена пакетов должны содержать суффикс основной версии (например, gtk2, gtk3, qt4, qt5). Для случаев, когда большинство зависимостей могут продолжать распространяться вместе с новейшим релизом, но некоторые не могут (например, закрытый исходный код, требующий libpng12 или аналогичный), устаревшая версия пакета может называться libfoo1, а текущая версия - просто libfoo.
- Версии пакетов должны быть такими же, как версия, выпущенная автором. Версии могут включать буквы, если это необходимо (например, версия nmap - 2.54BETA32). Теги версий не должны включать дефисы!. Только буквы, цифры и точки.
- Релизы пакетов - это специфические для Manjaro Linux пакеты. Они позволяют пользователям различать более новые и более старые сборки пакетов. Когда новая версия пакета выпускается впервые, счетчик релизов начинается с 1. Затем, по мере внесения исправлений и оптимизаций, пакет будет перевыпущен для публики Manjaro Linux и номер релиза будет увеличиваться. Когда выходит новая версия, счетчик релизов обнуляется до 1. Теги релизов пакетов следуют тем же ограничениям именования, что и теги версий.
Каталоги
- Конфигурационные файлы должны размещаться в каталоге
/etc
. Если существует более одного файла конфигурации, обычно принято использовать подкаталог, чтобы сохранить область/etc
как можно более чистой. Используйте/etc/{pkgname}/
, где{pkgname}
- имя пакета (или подходящую альтернативу, например, apache использует/etc/httpd/
).
- Файлы пакетов должны следовать этим общим рекомендациям по каталогам:
/etc
Системно-важные файлы конфигурации /usr/bin
Двоичные файлы /usr/lib
Библиотеки /usr/include
Файлы заголовков /usr/lib/{pkg}
Модули, плагины и тд. /usr/share/doc/{pkg}
Документация приложений /usr/share/info
Системные файлы GNU Info /usr/share/man
Страницы Man /usr/share/{pkg}
Данные приложений /var/lib/{pkg}
Постоянное хранение приложений /etc/{pkg}
Файлы конфигураций для {pkg}
/opt/{pkg}
Большие самодостаточные пакеты, такие как Java и т.д.
- Пакеты не должны содержать ни одного из следующих каталогов:
/dev
/home
/srv
/media
/mnt
/proc
/root
/selinux
/sys
/tmp
/var/tmp
/run
Обязанности Makepkg
Когда makepkg используется для сборки пакета, он автоматически выполняет следующие действия:
- Проверяет, установлены ли пакеты dependencies и makedepends.
- Загружает исходные файлы с серверов
- Проверяет целостность исходных файлов
- Распаковывает исходные файлы
- Применяет все необходимые патчи.
- Собирает программное обеспечение и устанавливает его в поддельный корень
- Удаляет символы из двоичных файлов
- Удаляет отладочные символы из библиотек
- Сжимает руководство и/или информационные страницы
- Генерирует мета-файл пакета, который включается в каждый пакет
- Сжимает поддельный корень в файл пакета
- Сохраняет файл пакета в настроенном каталоге назначения (cwd по умолчанию)
Архитектуры
Массив arch
должен содержать 'i686'
и/или 'x86_64'
в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать 'any'
для независимых от архитектуры пакетов.
Лицензии
Массив license внедряется в официальные репозитории, и его следует использовать и в ваших пакетах. Используйте его следующим образом:
- В [core] был создан пакет licenses, который хранит общие лицензии в /usr/share/licenses/common, т.е. /usr/share/licenses/common/GPL. Если пакет лицензирован по одной из этих лицензий, переменная licenses будет установлена в имя каталога, например license=('GPL').
- Если соответствующая лицензия не включена в пакет официальных лицензий, необходимо выполнить несколько действий:
- Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это - использовать:
install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
- Если исходный tarball НЕ содержит сведений о лицензии, а лицензия отображается, например, только на сайте, то скопируйте лицензию в файл и включите его. Не забудьте также назвать его как-нибудь подходяще.
- Добавьте 'custom' в массив лицензий. По желанию вы можете заменить 'custom' на 'custom: "имя лицензии"'.
- Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это - использовать:
- Как только лицензия используется в двух или более пакетах в официальном репозитории, включая [community], она становится общей
- Лицензии MIT, BSD, zlib/libpng и Python являются особыми случаями и не могут быть включены в пакет 'common' пакета лицензий. Для переменной license они рассматриваются как обычные лицензии (license=('BSD'), license=('MIT'), license=('ZLIB') или license=('Python')), но для файловой системы это пользовательские лицензии, поскольку каждая из них имеет свою собственную строку копирайта. Каждый пакет с лицензией MIT, BSD, zlib/libpng или Python должен иметь свою уникальную лицензию, хранящуюся в /usr/share/licenses/$pkgname/.
- На некоторые пакеты может распространяться не одна лицензия. В таких случаях в массиве лицензий может быть несколько записей, например license=("GPL" "custom:some commercial license"). Для большинства пакетов эти лицензии применяются в разных случаях, а не одновременно. Когда pacman получит возможность фильтрации по лицензиям (так что вы сможете сказать: "Мне нужны только программы с лицензиями GPL и BSD"), две (или более) лицензии будут рассматриваться pacman с использованием логики ИЛИ, а не И, поэтому pacman будет рассматривать приведенный выше пример как программу с лицензией GPL, независимо от других перечисленных лицензий.
- У (L)GPL есть много версий и перестановок этих версий. Для программ под (L)GPL существует следующая концепция:
- (L)GPL - (L)GPLv2 или любая поздняя версия
- (L)GPL2 - только (L)GPL2y
- (L)GPL3 - (L)GPL3 или любая поздняя версия
Предоставление пакетов в AUR
Перед отправкой пакетов в AUR обратите внимание на следующее:
- Представленные PKGBUILD НЕ ДОЛЖНЫ собирать приложения, уже находящиеся в любом из официальных бинарных репозиториев, ни при каких обстоятельствах. Исключением из этого строгого правила могут быть только пакеты, в которых включены дополнительные функции и/или исправления по сравнению с официальными. В этом случае массив pkgname должен быть другим, чтобы выразить эту разницу. Например. Пакет GNU screen PKGBUILD, содержащий патч sidebar, может быть назван screen-sidebar и т.д. Кроме того, массив provides=('screen') Массив PKGBUILD следует использовать чтобы избежать конфликтов с официальным пакетом.
-
Для обеспечения безопасности пакетов, отправляемых в AUR, пожалуйста, убедитесь, что вы правильно заполнили поле
md5sum
.md5sum
можно сгенерировать с помощью командыupdpkgsums
. -
Пожалуйста, добавьте строку комментария к верхней части файла
PKGBUILD
, который следует этому формату. Не забудьте замаскировать свой e-mail для защиты от спама:# Maintainer: Ваше Имя <address at домен dot ru>
Если вы берете на себя роль сопровождающего для существующего PKGBUILD, добавьте свое имя в верхнюю часть, как описано выше, и измените имя предыдущего сопровождающего(их) на Contributor:
# Maintainer: Ваше Имя <address at domain dot com> # Contributor: Предыдущее Имя <address at domain dot com>
-
Проверьте зависимости пакета (например, запустите
lddd
на динамических исполняемых файлах, проверить инструменты, требуемые скрипты и т.д.). Команда TU настоятельно рекомендует использовать утилитуnamcap
, написанную Джейсоном Чу (jason@archlinux.org), для анализа вменяемости пакетов.namcap
предупредит вас о неправильных разрешениях, отсутствующих зависимостях, ненужных зависимостях, и других распространенных ошибках. Вы можете установитьnamcap
с помощьюpacman
. Помните, чтоnamcap
можно использовать для проверки как файлов pkg.tar.gz, так и PKGBUILD - Зависимости являются наиболее распространенной ошибкой при упаковке. Namcap может помочь обнаружить их, но он не всегда корректен. Убедитесь в наличии зависимостей, изучив исходную документации и на веб-сайте программы.
- Не используйте
replaces
в PKGBUILD, если пакет не должен быть переименован, например, когда Ethereal стал Wireshark. Если пакет является альтернативной версией уже существующего пакета, используйтеconflicts
(иprovides
, если этот пакет требуется другим). Основное различие: после синхронизации (-Sy) pacman немедленно хочет заменить установленный "нарушающий" пакет, если встретит пакет с соответствующимreplaces
где-либо в своих репозиториях;conflicts
, с другой стороны, оценивается только при фактической установке пакета, что обычно является желаемым поведением, поскольку оно менее требовательно. -
Все файлы, загружаемые на AUR, должны содержаться в сжатом tar файле", содержащем каталог с
PKGBUILD
и дополнительные файлы сборки (патчи, install, ...) в нем.foo/PKGBUILD foo/foo.install foo/foo_bar.diff foo/foo.rc.conf
Имя архива должно содержать имя пакета например, foo.tar.gz.
Можно легко собрать tarball, содержащий все необходимые файлы, используя
makepkg --source
. Это создает tarball с именем$pkgname-$pkgver-$pkgrel.src.tar.gz
, который затем может быть загружен в AUR.Тарбол не должен содержать бинарный тарбол, созданный makepkg, и не должен содержать список файлов