Manjaro

Стандарты пакетов Manjaro

Revision as of 11:51, 22 February 2023 by Krotesk (talk | contribs) (Created page with "Помните, что {{ic|namcap}} можно использовать для проверки как файлов pkg.tar.gz, так и PKGBUILD </li> <li> '''Зависи...")
Other languages:
English • ‎русский

Представленные 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 используется для сборки пакета, он автоматически выполняет следующие действия:

  1. Проверяет, установлены ли пакеты dependencies и makedepends.
  2. Загружает исходные файлы с серверов
  3. Проверяет целостность исходных файлов
  4. Распаковывает исходные файлы
  5. Применяет все необходимые патчи.
  6. Собирает программное обеспечение и устанавливает его в поддельный корень
  7. Удаляет символы из двоичных файлов
  8. Удаляет отладочные символы из библиотек
  9. Сжимает руководство и/или информационные страницы
  10. Генерирует мета-файл пакета, который включается в каждый пакет
  11. Сжимает поддельный корень в файл пакета
  12. Сохраняет файл пакета в настроенном каталоге назначения (cwd по умолчанию)

Архитектуры

Массив arch должен содержать 'i686' и/или 'x86_64' в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать 'any' для независимых от архитектуры пакетов.

Licenses

The license array is being implemented in the official repos, and it should be used in your packages as well. Use it as follows:

  • A licenses package has been created in [core] that stores common licenses in /usr/share/licenses/common ie. /usr/share/licenses/common/GPL. If a package is licensed under one of these licenses, the licenses variable will be set to the directory name e.g. license=('GPL')
  • If the appropriate license is not included in the official licenses package, several things must be done:
    1. The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/LICENSE. One good way to do this is by using: 
      install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    2. If the source tarball does NOT contain the license details and the license is only displayed on a website for example, then copy the license to a file and include it. Remember to call it something appropriate too.
    3. Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.
  • Once a licenses is used in two or more packages in an official repo, including [community], it becomes common
  • The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkg. For the sake of the license variable, it is treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it is a custom license, because each one has its own copyright line. Each MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.
  • Some packages may not be covered by a single license. In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license"). For the majority of packages these licenses apply in different cases, as opposed to applying at the same time. When pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.
  • The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:
    • (L)GPL - (L)GPLv2 or any later version
    • (L)GPL2 - (L)GPL2 only
    • (L)GPL3 - (L)GPL3 or any later version

Предоставление пакетов в AUR

Перед отправкой пакетов в AUR обратите внимание на следующее:

  1. Представленные PKGBUILD НЕ ДОЛЖНЫ собирать приложения, уже находящиеся в любом из официальных бинарных репозиториев, ни при каких обстоятельствах. Исключением из этого строгого правила могут быть только пакеты, в которых включены дополнительные функции и/или исправления по сравнению с официальными. В этом случае массив pkgname должен быть другим, чтобы выразить эту разницу. Например. Пакет GNU screen PKGBUILD, содержащий патч sidebar, может быть назван screen-sidebar и т.д. Кроме того, массив provides=('screen') Массив PKGBUILD следует использовать чтобы избежать конфликтов с официальным пакетом.
  2. Для обеспечения безопасности пакетов, отправляемых в AUR, пожалуйста, убедитесь, что вы правильно заполнили поле md5sum. md5sum можно сгенерировать с помощью команды updpkgsums.
  3. Пожалуйста, добавьте строку комментария к верхней части файла PKGBUILD, который следует этому формату. Не забудьте замаскировать свой e-mail для защиты от спама: 
    # Maintainer: Ваше Имя <address at домен dot ru>

    Если вы берете на себя роль сопровождающего для существующего PKGBUILD, добавьте свое имя в верхнюю часть, как описано выше, и измените имя предыдущего сопровождающего(их) на Contributor: 

    # Maintainer: Ваше Имя <address at domain dot com>
# Contributor: Предыдущее Имя <address at domain dot com>
  4. Проверьте зависимости пакета (например, запустите lddd на динамических исполняемых файлах, проверить инструменты, требуемые скрипты и т.д.). Команда TU настоятельно рекомендует использовать утилиту namcap, написанную Джейсоном Чу (jason@archlinux.org), для анализа вменяемости пакетов. namcap предупредит вас о неправильных разрешениях, отсутствующих зависимостях, ненужных зависимостях, и других распространенных ошибках. Вы можете установить namcap с помощью pacman. Помните, что namcap можно использовать для проверки как файлов pkg.tar.gz, так и PKGBUILD
  5. Зависимости являются наиболее распространенной ошибкой при упаковке. Namcap может помочь обнаружить их, но он не всегда корректен. Убедитесь в наличии зависимостей, изучив исходную документации и на веб-сайте программы.
  6. Не используйте replaces в PKGBUILD, если пакет не должен быть переименован, например, когда Ethereal стал Wireshark. Если пакет является альтернативной версией уже существующего пакета, используйте conflicts (и provides, если этот пакет требуется другим). Основное различие: после синхронизации (-Sy) pacman немедленно хочет заменить установленный "нарушающий" пакет, если встретит пакет с соответствующим replaces где-либо в своих репозиториях; conflicts, с другой стороны, оценивается только при фактической установке пакета, что обычно является желаемым поведением, поскольку оно менее требовательно.
  7. Все файлы, загружаемые на 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, и не должен содержать список файлов

Retrieved from "https://wiki.manjaro.org/index.php?title=Manjaro_Packaging_Standards/ru&oldid=47130"