Стать мэинтейнером. Часть третья

[Takeji]

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

Это не правильный подход, так как баг с таким номером может существовать и относится к другой программе. В случаях когда нет номера ITP в changelog'е пишется следующее:

* Non-maintainer upload

вместо

* Initial release (Closes: #123456)

[torkve]

Non-maintainer upload мы пишем, когда не мы являемся сопровождающим пакета.

[Takeji]

Мы это пишем когда не являемся официальным сопровождающим пакета Debian GNU/Linux и не можем сделать ITP через bug tracking system

[torkve]

А в каких случаях, хотел бы я знать, мы не можем сделать ITP через BTS, если мы планируем стать официальным сопровождающим пакета?

[Takeji]

Стать официальным сопровождающим не так-то и легко. Поэтому между намерением сделать ITP и его фактическим осуществлением может пройти много времени. И когда это все-таки произойдет, тогда мы сможем указывать номер бага. До тех пор лучше писать «non-maintainer upload»

[torkve]

Мм, в моём представлении надо делать не так. Надо СРАЗУ подавать ITP, как только принимается решение создать пакет (потому что в теории его могут завернуть еще на этой стадии, сказав, что он нафиг в дебиане не нужен). Соответственно, как только вы подаёте ITP, у вас есть номер бага, который вы можете в чейнджлог вписать. Когда вы этот пакет выложите в репозиторий — дело десятое. А даже если его не выложите вообще никогда, то в дебиане уже будет лежать готовый ITP, а процедуру передача или «захвата» сопровождения пакета для таких случаев никто не отменял.

[darkk]

Славная статья, надо будет пофиксить баги :-)

[shutnik]

ничего страшного в экспериментальном репозитории нет
использую sid + некоторые пакеты из experimantal, доволен

[aiz]

насколько я понял из текста, имелось ввиду не подключение debian «experimental» к другой ветви debian, а к ubuntu — а вот здесь действительно могут быть некоторые проблемы (вроде поломанных зависимостей)

[torkve]

Ну, я писал про подключение experimental к debian'у (мне было лень смотреть, есть ли в ubuntu новая версия пакета, и где — в intrepid, jaunty или еще где), просто если не выставлять никаких флагов по использованию, система, обнаружив новые версии пакетов, обновит всё до experimental, что не есть хорошо :)

[Vadi2]

Ну теперь можешь загнать файл на PPA (https://help.launchpad.net/Packaging/PPA#Overview) и иметь свой репозитарий.

[aiz]

интересные статьи. но, имхо, стоило всё таки начать с pbuilder'а (а не заканчивать на нём :-), т.к. обычно ни debuild, ни dpkg-buildpackage в чистом виде для сборки пакетов не используются (ибо мусора много в систему тащат в виде ненужных пакетов для удовлетворения зависимостей при сборке); что касается утилит проверки пакета на кошерность, рекомендую(если не сталкивались) обратить внимание на piuparts — проверяет в chroot-окружении, созданном pbuilder'ом, не перезаписывает/удаляет/создаёт/оставляет ли собранный пакет при установке/удалении какие-либо лишние файлы в системе.
И ещё, помимо создания собственного репозитария, думаю, полезной будет заметка наподобие «куда выгружать пакеты, если их не приняли в Ubuntu» и рассказать в ней про использование PPA.

[Takeji]

обычно ни debuild, ни dpkg-buildpackage в чистом виде для сборки пакетов не используются (ибо мусора много в систему тащат в виде ненужных пакетов для удовлетворения зависимостей при сборке)

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

[Outspector]

Вот как раз для этого и нужно продолжение статьи про pbuilder, чтобы из нее узнать, что этот pbuilder собирает все пакеты в chroot-е и не тащит мусор в рабочую систему.

[Takeji]

При установке пакета собранного в chroot'e большая часть этого «мусора» вернется… При этом ее придется скачивать и ставить заново

[aiz]

отнюдь! есть два типа совершенно разных, никак не коррелирующих между собой понятия: зависимости для сборки(компиляции) и зависимости для установки пакета — Build-Depends и Depends поля соответственно, в debian/control. И значения этих полей для пакетов как правило не равны — Build-Depends обычно в разы длиннее и шире; и потом, зачем пользователю, который всего лишь хочет собрать пакет, устанавливать в работающую систему кучу *-dev пакетов на сотню мегабайт с заголовочными файлами, которые а) впоследствии пользователем использоваться в разрабатываемых им программах использоваться не будут; б) не нужны для установки и работы собственно собранного пакета. pbuilder как раз решает все эти проблемы, а мой комментарий лишь к тому был сказан, что обычно с pbuilder'а в различных howto начинают повествование о сборках deb-пакетов, а не заканчивают.

[torkve]

Я посчитал неверным начинать с pbuilder'а. На мой взгляд как раз последовательность довольно логична — сначала рассказать о логике дистрибутива вообще, затем — о том, как именно устроены пакеты и как их собирать и только потом надо рассказывать о создании репозитория, сборке pbuilder'ом и всякой возможной автоматизации.
Как пользователь может собирать пакет загадочным pbuilder'ом, когда еще даже непонятно, как вообще устроен и собирается пакет — а тут еще и добавляется какое-то распаковывание системы в chroot, установка пакетов, потом запаковывание обратно… если так сразу это всё давать, пользователя и испугать может :)

[sitehound]

Мои мечты о каком-то простом создателе deb-ов развеялись в лучах утреннего солнца.

[torkve]

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