AUR submission guidelines (Русский)

Состояние перевода: На этой странице представлен перевод статьи AUR submission guidelines. Дата последней синхронизации: 27 сентября 2024. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Пользователи могут делиться своими скриптами PKGBUILD, публикуя их в пользовательском репозитории Arch (AUR). Он не содержит каких-либо бинарных пакетов, но позволяет пользователям публиковать PKGBUILD, которые могут быть скачаны другими пользователями. Эти PKGBUILD являются полностью неофициальными и не проходят тщательную проверку, поэтому используйте их на свой страх и риск.

Отправка пакетов

Важно: Ожидается, что перед отправкой пакета вы ознакомитесь со стандартами создания пакетов для Arch, а также всеми статьями из блока ссылок по теме. Крайне внимательно проверяйте правильность загружаемых вами пакетов. Пакеты, нарушающие правила, могут быть удалены без предупреждения.

Если вы дважды прочитали этот раздел и всё равно не уверены в корректности своего пакета и/или процесса сборки, отправьте свой PKGBUILD в список рассылки AUR, на форум AUR или форумы Arch, или попросите ревью своего пакета в канале IRC.

Правила отправки пакетов

При отправке пакетов в AUR придерживайтесь следующих правил:

Отправляемые PKGBUILD'ы не должны собирать приложения, которые уже есть в официальных бинарных репозиториях. Проверьте официальную базу данных пакетов на наличие этого пакета. Если для него существует любая версия, не выкладывайте пакет. Если официальный пакет устарел, пометьте его как устаревший. Если официальный пакет заброшен или не предоставляет какую-либо функцию, отправьте сообщение об ошибке.

Исключением из этого строгого правила могут быть только пакеты, в которых есть дополнительная функциональность и/или патчи. В таком случае pkgname должно быть другим, чтобы выразить это различие. Например, пакет для GNU screen, содержащий патч sidebar, может быть назван screen-sidebar. Дополнительно следует использовать массив conflicts=('screen'), чтобы избежать конфликтов с официальным пакетом.

Проверьте AUR на наличие этого пакета. Если он в настоящее время поддерживается, о необходимых изменениях можно написать в комментариях, чтобы мейнтейнер обратил на это внимание. Если он не поддерживается, вы можете взять сопровождение этого пакета на себя и обновлять его по мере необходимости. Не создавайте дублирующиеся пакеты.

Убедитесь, что пакет, который вы хотите загрузить, полезен. Захочет ли кто-нибудь ещё использовать этот пакет? Не слишком ли он узкоспециализированный? Если он будет полезен более, чем ограниченной группе людей, пакет подходит для AUR.

AUR и официальные репозитории предназначены для пакетов, которые устанавливают общее программное обеспечение и связанное с ним содержимое, в частности: исполняемые файлы; файлы настроек; онлайн- или оффлайн-документация для конкретных программ или дистрибутива Arch Linux в целом; медиафайлы, используемые программным обеспечением напрямую.

Не используйте replaces в файлах PKGBUILD для AUR, кроме случая, когда пакет переименовывается, например, как Ethereal переименовался в Wireshark. Если пакет является альтернативной версией уже существующего пакета, используйте conflicts (и provides, если этот пакет требуется другим пакетам). Основное различие заключается в следующем: после синхронизации (-Sy) pacman немедленно захочет заменить установленный пакет, если встретит пакет с соответствующим значением replaces где-либо в своих репозиториях; conflicts, с другой стороны, оценивается только при фактической установке пакета, что обычно является желаемым поведением, поскольку оно менее инвазивно.

Названия пакетов, которые берут исходный код из системы контроля версий и при этом не привязаны к конкретной версии, должны иметь соответствующий суффикс, например -git для git. Список суффиксов приведён в разделе VCS package guidelines#Package naming.

Если пакет содержит прекомпилированные файлы (deliverables), для которых доступен исходный код, название должно иметь суффикс -bin. Исключением является Java. AUR не должен содержать бинарный tar-файл, созданный с помощью makepkg, а также список файлов.

Названия пакетов, которые берут исходный код конкретной версии, не используют суффикс.

Добавьте комментарий в начале файла PKGBUILD, содержащий информацию о текущих (maintainers) и предыдущих (contributors) сопровождающих, соблюдая следующий формат. Не забудьте замаскировать свой e-mail для защиты от спама. Дополнительные строки являются опциональными.

Примечание: Использование обфускации при указании адресов электронной почты затрудняет контакт с вами.

Если вы берёте на себя роль сопроводителя существующего PKGBUILD, добавьте своё имя в начало следующим образом:

# Maintainer: Ваше Имя <address at domain dot tld>

Если были предыдущие сопровождающие, укажите их как контрибьюторов. То же самое относится к первоначальному автору, если это не вы. Если сопровождающих несколько, добавьте имена других сопровождающих тоже.

# Maintainer: Ваше Имя <address at domain dot tld>
# Maintainer: Имя другого сопровождающего <address at domain dot tld>
# Contributor: Имя предыдущего сопровождающего <address at domain dot tld>
# Contributor: Имя оригинального автора пакета <address at domain dot tld>

Аутентификация

Для получения возможности отправки пакета в AUR необходимо иметь ключи SSH. Скопируйте свой открытый ключ в профиль на сайте AUR, а закрытый ключ настройте на использование для хоста aur.archlinux.org. Например:

~/.ssh/config

Host aur.archlinux.org
  IdentityFile ~/.ssh/aur
  User aur

Следует сгенерировать новую пару ключей специально для AUR вместо использования существующей: это позволит выборочно отзывать ключи, если что-то случится:

$ ssh-keygen -f ~/.ssh/aur

Совет: Можно добавить несколько открытых ключей в свой профиль, по одному на строку.

Создание репозитория для пакета

Если вы создаёте новый пакет с нуля, создайте локальный Git-репозиторий и удалённый на AUR путём клонирования предполагаемого pkgbase. Если пакет ещё не существует, появится следующее предупреждение:

$ git -c init.defaultBranch=master clone ssh://aur@aur.archlinux.org/pkgbase.git

Клонирование в «pkgbase»…
warning: Похоже, что вы клонировали пустой репозиторий.

Примечание: Если pkgbase соответствует ранее удалённому пакету, репозиторий не будет пустым.

Если у вас уже есть пакет, инициализируйте его как git-репозиторий (если его ещё нет):

$ git -c init.defaultBranch=master init

и добавьте AUR remote:

$ git remote add метка ssh://aur@aur.archlinux.org/pkgbase.git

Затем сделайте fetch для него, чтобы репозиторий инициализировался на стороне AUR.

Примечание: Сделайте pull и rebase, чтобы решить конфликты в случае, если pkgbase соответствует удалённому пакету.

Отправка пакета

Важно: По умолчанию для указания авторства коммитов используются имя и почта из глобальных настроек Git. Если вы не хотите публиковать ваши персональные данные, не забудьте установить локальное имя пользователя и электронную почту с помощью git config user.name "..." и git config user.email "...". Изменить опубликованные коммиты крайне трудно (FS#45425). Проверяйте ваши коммиты до их отправки!

При отправке новой версии пакета обновите переменные pkgver или pkgrel, чтобы уведомить пользователей о необходимости обновления. Не обновляйте их при незначительных изменениях в PKGBUILD вроде исправления несущественных опечаток.

Для пакетов VCS не публикуйте изменения, которые только обновляют pkgver. Такие пакеты не считаются устаревшими, если в апстриме появились новые коммиты. Публикуйте новую версию только в случае внесения других изменений, например, при изменении процесса сборки.

Не забудьте сгенерировать новый .SRCINFO при обновлении метаданных в PKGBUILD, например при изменении pkgver(); в противном случае AUR не отобразит обновлённый номер версии.

Для публикации пакета добавьте как минимум PKGBUILD и .SRCINFO, а затем любые вспомогательные файлы (например, файлы .install или локальные исходные файлы, такие как патчи), создайте коммит с информативным комментарием и отправьте изменения в AUR с помощью push.

Пример:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "информативное сообщение коммита"
$ git push

Примечание:

Если вы забыли добавить в коммит файл .SRCINFO, отредактируйте коммит с помощью git commit --amend, добавив в него файл, чтобы AUR позволил выполнить push.
AUR позволяет выполнять push только в ветку master. Если локальная ветка имеет другое название, переименуйте её.

Совет: Чтобы содержать рабочий каталог и коммиты в чистоте, создайте gitignore(5), исключающий все файлы, и принудительно добавляйте файлы по мере необходимости.

Поддержка пакетов

Поддерживайте обратную связь: следите за комментариями других пользователей и вносите улучшения, которые они предлагают. Относитесь к этому, как к процессу обучения!
Пожалуйста, не пишите комментарии с новым номером версии при каждом обновлении пакета. Благодаря этому раздел комментариев будет удобен для полезного содержимого, о котором упомянуто выше.
Не забрасывайте свои пакеты! Именно создатель пакета должен его сопровождать, проверять обновления и улучшать PKGBUILD.
Если вы по каким-то причинам больше не хотите продолжать поддерживать пакет, откажитесь от него (disown) в веб-интерфейсе AUR и/или отправьте сообщение в почтовую рассылку AUR. Если все сопровождающие откажутся от пакета, пакет будет отмечен как заброшенный («orphaned»).
Автоматизация является ценным инструментом для сопровождающих, но она не может заменить ручное вмешательство (например, в проектах могут меняться лицензии, добавляться или удаляться зависимости и происходить другие значимые изменения даже для минорных релизов). Автоматизация обновлений PKGBUILD выполняется на ваш страх и риск, и любые проблемные аккаунты и их пакеты могут быть удалены без предупреждения.

Запросы

Запросы на удаление, слияние и отказ от поддержки пакета можно создать, нажав на ссылку «Отправить запрос» в разделе «Действия над пакетом» справа. В этом случае автоматически будет отправлено уведомление текущему мэйнтейнеру пакета по электронной почте и в почтовую рассылку aur-requests для обсуждения. После этого сопровождающие пакетов примут или отвергнут запрос.

Удаление

Запрос на скрытие pkgbase из AUR. Требуется краткое пояснение причины удаления, а также подтверждающая информация (например, то, что содержимое пакета предоставляется другим пакетом, или то, что он был переименован с согласия владельца, и т. д.).

Примечание:

Комментариев на странице пакета недостаточно для указания причины его удаления: имейте в виду, что как только сопровождающий пакетов выполнит запрос, единственное место, в котором останется информация о пакете, — почтовая рассылка aur-requests.
Запросы на удаление могут быть отклонены, и в этом случае, если вы являетесь сопровождающим, вам скорее всего будет рекомендовано отказаться от пакета, чтобы его мог принять другой сопровождающий.
После «удаления» пакета его git-репозиторий остаётся доступен в AUR, и его можно клонировать.

Слияние

Запрос на удаление pkgbase и перенос всех его голосов и комментариев в другой pkgbase. Необходимо указать имя того пакета, в который нужно слиться.

Примечание: Это не имеет никакого отношения к git merge или запросам на слияние в GitLab.

Отказ

Запрос на отказ от поддержки pkgbase. Будет выполнен после двух недель, если текущий сопровождающий не вмешается. Исключением является ситуация, если пакет отмечен как устаревший более 180 дней; в таком случае запрос принимается автоматически.