Manjaro Difference between revisions of "Manjaro Packaging Standards/ru"

Difference between revisions of "Manjaro Packaging Standards/ru"

From Manjaro
(Created page with "Помните, что {{ic|namcap}} можно использовать для проверки как файлов pkg.tar.gz, так и PKGBUILD </li> <li> '''Зависи...")
(Created page with "==Лицензии== Массив license внедряется в официальные репозитории, и его <b>следует</b> использо...")
Line 207: Line 207:
==Архитектуры==
==Архитектуры==
Массив {{Ic|arch}} должен содержать {{Ic|'i686'}} и/или {{Ic|'x86_64'}} в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать {{Ic|'any'}} для независимых от архитектуры пакетов.
Массив {{Ic|arch}} должен содержать {{Ic|'i686'}} и/или {{Ic|'x86_64'}} в зависимости от того, на какой архитектуре может быть собран пакет. Вы также можете использовать {{Ic|'any'}} для независимых от архитектуры пакетов.
<div lang="en" dir="ltr" class="mw-content-ltr">
==Лицензии==
==Licenses==
Массив [[Licenses|license]] внедряется в официальные репозитории, и его <b>следует</b> использовать и в ваших пакетах. Используйте его следующим образом:
The [[Licenses|license]] array is being implemented in the official repos, and it <b>should</b> be used in your packages as well. Use it as follows:
<ul>
<ul>
<li>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')</li>
<li>В [core] был создан пакет licenses, который хранит общие лицензии в /usr/share/licenses/common, т.е. /usr/share/licenses/common/GPL.  Если пакет лицензирован по одной из этих лицензий, переменная licenses будет установлена в имя каталога, например license=('GPL').</li>
<li>If the appropriate license is not included in the official licenses package, several things must be done:
<li>Если соответствующая лицензия не включена в пакет официальных лицензий, необходимо выполнить несколько действий:
<ol>
<ol>
<li>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:
<li>Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это - использовать:
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
</li>
</li>
<li>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.
<li>Если исходный tarball НЕ содержит сведений о лицензии, а лицензия отображается, например, только на сайте, то скопируйте лицензию в файл и включите его. Не забудьте также назвать его как-нибудь подходяще.
<li>Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.</li>
<li>Добавьте 'custom' в массив лицензий. По желанию вы можете заменить 'custom' на 'custom: "имя лицензии"'.</li>
</ol></li>
</ol></li>
<li>Once a licenses is used in two or more packages in an official repo, including [community], it becomes common</li>
<li>Как только лицензия используется в двух или более пакетах в официальном репозитории, включая [community], она становится общей</li>
<li>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/.</li>
<li>Лицензии MIT, BSD, zlib/libpng и Python являются особыми случаями и не могут быть включены в пакет 'common' пакета лицензий. Для переменной license они рассматриваются как обычные лицензии (license=('BSD'), license=('MIT'), license=('ZLIB') или license=('Python')), но для файловой системы это пользовательские лицензии, поскольку каждая из них имеет свою собственную строку копирайта. Каждый пакет с лицензией MIT, BSD, zlib/libpng или Python должен иметь свою уникальную лицензию, хранящуюся в /usr/share/licenses/$pkgname/.</li>
<li>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.</li>
<li>На некоторые пакеты может распространяться не одна лицензия. В таких случаях в массиве лицензий может быть несколько записей, например license=("GPL" "custom:some commercial license"). Для большинства пакетов эти лицензии применяются в разных случаях, а не одновременно.  Когда pacman получит возможность фильтрации по лицензиям (так что вы сможете сказать: "Мне нужны только программы с лицензиями GPL и BSD"), две (или более) лицензии будут рассматриваться pacman с использованием логики ИЛИ, а не И, поэтому pacman будет рассматривать приведенный выше пример как программу с лицензией GPL, независимо от других перечисленных лицензий.</li>
<li>The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:</li>
<li>У (L)GPL есть много версий и перестановок этих версий. Для программ под (L)GPL существует следующая концепция:</li>
<ul>
<ul>
<li>(L)GPL - (L)GPLv2 or any later version</li>
<li>(L)GPL - (L)GPLv2 or any later version</li>
Line 231: Line 230:
</li>
</li>
</ul>
</ul>
</div>
==Предоставление пакетов в AUR==
==Предоставление пакетов в AUR==
<p>Перед отправкой пакетов в AUR обратите внимание на следующее:</p>
<p>Перед отправкой пакетов в AUR обратите внимание на следующее:</p>

Revision as of 11:58, 22 February 2023

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' для независимых от архитектуры пакетов.

Лицензии

Массив license внедряется в официальные репозитории, и его следует использовать и в ваших пакетах. Используйте его следующим образом:

  • В [core] был создан пакет licenses, который хранит общие лицензии в /usr/share/licenses/common, т.е. /usr/share/licenses/common/GPL. Если пакет лицензирован по одной из этих лицензий, переменная licenses будет установлена в имя каталога, например license=('GPL').
  • Если соответствующая лицензия не включена в пакет официальных лицензий, необходимо выполнить несколько действий:
    1. Файл(ы) лицензии должны быть включены в /usr/share/licenses/$pkgname/, например, /usr/share/licenses/dibfoo/LICENSE. Один из хороших способов сделать это - использовать: 
      install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    2. Если исходный tarball НЕ содержит сведений о лицензии, а лицензия отображается, например, только на сайте, то скопируйте лицензию в файл и включите его. Не забудьте также назвать его как-нибудь подходяще.
    3. Добавьте 'custom' в массив лицензий. По желанию вы можете заменить 'custom' на 'custom: "имя лицензии"'.
  • Как только лицензия используется в двух или более пакетах в официальном репозитории, включая [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 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=47132"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.