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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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. Например:

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

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

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

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

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

$ git remote add метка ssh://[e-mail]/pkgbase.git

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

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

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

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

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

Пример:

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

Примечание: Если вы забыли добавить в коммит файл .SRCINFO, и добавили его в последующем коммите, AUR откажет в записи пакета, потому что .SRCINFO должен присутствовать в каждом изменении. Чтобы решить эту проблему, можно использовать git rebase с параметром --root или git filter-branch с параметром --tree-filter.

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

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

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

Запросы

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

• Запросы на отказ от поддержки пакета будут выполнены после двух недель, если текущий мэйнтейнер не вмешается. Исключением является ситуация, если пакет отмечен как устаревший более 180 дней; в таком случае запрос принимается автоматически.
• Запросы на слияние предназначены для удаления package base и переноса всех его голосов и комментариев в другой package base. Необходимо указать имя package base, в которую нужно слиться. Обратите внимание, что это не имеет ничего общего с 'git merge' или запросами на слияние в GitLab.
• Запросы на удаление должны содержать следующую информацию:
  • Краткое описание причины удаления. Имейте в виду, что только лишь комментариев к пакету недостаточно для указания причины его удаления. Чтобы доверенные пользователи предприняли какие-либо действия, единственное место, куда следует отправлять данную информацию — почтовая рассылка aur-requests.
  • Информацию по поддержке: например, то, что содержимое пакета предоставляется другим пакетом, или то, что он был переименован с согласия владельца, и т.д.
• После удаления пакета его Git-репозиторий остаётся доступен в AUR.