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

Состояние перевода:
На этой странице представлен перевод статьи
AUR submission guidelines
. Дата последней синхронизации: 27 сентября 2024. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Ссылки по теме
Стандарты создания пакетов для Arch
Package Maintainer guidelines
Пользователи могут
делиться
своими скриптами
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 дней; в таком случае запрос принимается автоматически.