Процедура загрузки пакета в архивы Debian

надо будет ответить на определённые вопросы. Чем в этом случае ограниченные права загрузки отличаются от неограниченных?

Какие ещё вопросы? Вооде DM может загружать свои пакеты, а DD - любые.

Правильно ли я понимаю, что после того, как загруженный пакет повисит в специальной очереди, он попадёт в debian/pool?

Чтобы выбраться из песочницы mentors, нужно найти спонсора и получить аппрув от него.

Как будет осуществляться определение, в какой дистрибутив загружается пакет? Это указывается в каких-то метаданных пакета (debian/*), или же указывается мейнтейнером при загрузке, или это решается кем-то другим?

Прочитай всё-таки https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload

5.) Как осуществляется перемещение из experimental в unstable?

Никак

2.) Я не про те пакеты, которые mentors/sponsors, а обычные пакеты, загружаемые мейнтейнерами

5.) Ну не может же быть никак. Руками или автоматом?

3.) Вроде, прочитал, но на этот вопрос ответа так и не нашёл.

Each upload needs to specify which distribution the package is intended for. The package build process extracts this information from the first line of the debian/changelog file and places it in the Distribution field of the .changes file.

There are several possible values for this field: stable, unstable, testing-proposed-updates and experimental. Normally, packages are uploaded into unstable.

2) Ты ведь мог сам догадаться, что пакет должен как минимум собраться, а зеркала - обновиться? Или я опять не понимаю, чего ты хочешь

5) experimental это отдельная ветка (точнее, просто набор пакетов), не связанная с циклом unstable-testing-stable. Какой смысл иметь ещё один unstable?

А, я прочитал не всю статью, а ты кинул ссылку на сектор, в котором нет этих слов. Извини за тупняк.

2.) Вероятно, мы друг друга не понимаем. Вот, допустим, я - человек, имеющий право загрузки в Debian, и у меня есть некий пакет. Я его загружаю в UploadQueue. Там он проходит какую-то череду тестов. После этого он уже непосредственно падает в pool официального архива Debian и добавляется в соответствующий дистрибутив, или требуются какие-то ещё операции? Про синк зеркал я знаю.

5.) Вроде же, некоторые пакеты, после обкатки в experimental, попадают в unstable. Получается, что делается это сугубо сознательно и руками, а не автоматом?

Начнем с вопроса в PS. Debian Developer - это человек, который имеет право загрузки любого пакета в дистрибутив. При этом часто Debian developer занимается еще какими-нибудь делами (поддержка инфраструктуры, работа с кандидатами в разработчики, и т.п.). Кроме этого, Debian developer имеет право голосовать по вопросам, вынесенным на всеобщее голосование. Debian Maintainer - это человек, который имеет право загружать пакеты, которые ему разрешил загружать какой-то из Debian Developer'ов.

Теперь, что смогу из пунктов:

1) С помощью спонсора загрузить пакет может вообще кто угодно. Другое дело, что спонсоры обычно как-то стараются убедиться, что тот, кто предложил пакет для загрузки, не сбежит и не бросит это самый пакет. Про отличие ограниченных прав от неограниченных см. выше.

2) Попадет, непременно попадет, если аплоад удался, то есть в пакете нет немедленной ошибки (например, в заголовочном файле .dsc какой-то файл присутствует, а загрузить его забыли, или повторно загрузили .orig.tar.gz существующей версии, отличающийся от загруженного ранее, или еще что-нибудь такое же очевидное).

3) Дистрибутив, куда загружать пакет, определяется первой строкой в файле debian/changelog в дистрибутиве исходных текстов. Формально, имя дистрибутива из этой строки переписывается в файл .changes при сборке пакета и потом уже на стороне сервера имя дистрибутива берется из изменений. (Небось, можно и руками .changes править, но я не пробовал.)

4) Да, при загрузке указывается «срочность» пакета (low, medium или high, по умолчанию сейчас принята medium). Далее, в зависимости от срочности, и если никто не написал сообщение о достаточно серьезной ошибке в данной версии пакета, через 10, 5 или 2 дня он переезжает в testing. Еще одно непременное условие - пакет должен собраться на всех архитектурах, для которых он уже присутствует в testing. Если какую-то архитектуру надо выбросить из поддерживаемых, то для этого есть специальная процедура.

5) Автоматичеси никак. Но сопровождающий, если захочет, может, мало что изменив в пакете, который есть в experimental, загрузить его в unstable, если посчитает нужным.

Надеюсь, что хоть что-то прояснилось после этих ответов.

Большое спасибо! Ответы по Эксперименталу, категориям разработчиков Дебиан и спонсорстве были особенно полезны.

Немного не по теме, но не могли бы Вы подсказать, где прочитать об обозначении версий пакетов в Debian? Я понял модель [epoch:]upstream_version[-debian_revision], но иногда в версию также дописываются dfsg, bpo и другие выражения. Я логически понимаю, что речь идёт о соответствии dfsg или бэкпортировании, но я не нашёл, где это задокументировано.

И ещё: нет ли где перевода на русский этой (https://www.debian.org/doc/debian-policy/ch-controlfields.html) статьи? Я читал про сравнение версий (5.6.12, низ) и у меня вскипел мозг.

Оно, конечно, и правда не по теме, но что-то все-таки постараюсь рассказать про версии. К сожалению, одного документа, в котором бы описывались все возможные варианты debian revision, не существует. Строчки, приписываемые в бекпортах, описаны где-то на backports.debian.org, а есть еще и обновления в стабильном дистрибутиве, и бинарные NMU, и просто NMU.

Вкратце так:

1. Если пакет загружен сопровождающим в обычном режиме, то к версии просто приписывается -1, -2, -3 и т.п. (При загрузке в experimental разнообразие гораздо больше, там попадаются и -0, и -0exp1, и -1~exp1, тильда в последней строке приводит к тому, что -1~exp1 сортируется перед -1, а значит, когда настоящая версия -1 попадет в unstable, пакет обновится.)

2. Если пакет загружен кем-то кроме сопровождающего (NMU - non-maintainer upload), то версия устроена так: -1.1, -1.2 и т.п. (хотя бывают и варианты типа -1+nmu1, -1+nmu2, ... Суффикс +nmu неизбежно возникает, если в исходном пакете нет debian revision)

3. Если это загрузка для пересборки (бывает, когда меняется ABI библиотек, от которых зависит пакет), то так: -1+b1, -1+b2

4. Если это обновление в стабильной ветке (неважно, security fix или просто fix), то debian revision сейчас выглядит так: -1+deb8u1 (первое обновление для версии дистрибутива 8)

5. Если это бекпорт в текущую стабильную ветку, то так: -1~bpo8+1 (тильда опять нужна, чтобы потом при обновлении пакет с -1 успешно обновил этот бекпорт). При этом категорически запрещено бекпортировать пакеты новее, чем есть в testing, что означает, что когда этот testing наконец превратится в stable, пакет из бекпорта обновится.

Что же касается суффикса dfsg, то он приписывается не к debian revision, а к версии оригинального пакета с исходниками, если сопровождающий был вынужден его перепаковать из-за нарушений DFSG (чаще всего это какой-нибудь бинарник без исходников или файл с несвободной лицензией в тарболе). При этом бывает и просто dfsg, и -dfsg, и +dfsg и +dfsg1, в общем, самые разные варианты.

Про перевод раздела, описывающего сортировку версий, я не слышал. Видимо, он мало кому интересен. Но в нем в общем-то два интересных пункта: во-первых, «эпоха», которая приписывается в начало версии в тех случаях, когда либо апстрим изменяет систему версий у себя, либо случается какая-то ошибка при пакетировании, и во-вторых, интересная штука - тильда, приписывание которой к версии уменьшает ее.