Комментарии 19
Поскольку подобного бага у нас заведено не было, мы поставим там произвольный номер до тех времен, когда соберемся включать пакет в официальный репозиторий.
Это не правильный подход, так как баг с таким номером может существовать и относится к другой программе. В случаях когда нет номера ITP в changelog'е пишется следующее:
* Non-maintainer uploadвместо
* Initial release (Closes: #123456)
Non-maintainer upload мы пишем, когда не мы являемся сопровождающим пакета.
Мы это пишем когда не являемся официальным сопровождающим пакета Debian GNU/Linux и не можем сделать ITP через bug tracking system
А в каких случаях, хотел бы я знать, мы не можем сделать ITP через BTS, если мы планируем стать официальным сопровождающим пакета?
Стать официальным сопровождающим не так-то и легко. Поэтому между намерением сделать ITP и его фактическим осуществлением может пройти много времени. И когда это все-таки произойдет, тогда мы сможем указывать номер бага. До тех пор лучше писать «non-maintainer upload»
Мм, в моём представлении надо делать не так. Надо СРАЗУ подавать ITP, как только принимается решение создать пакет (потому что в теории его могут завернуть еще на этой стадии, сказав, что он нафиг в дебиане не нужен). Соответственно, как только вы подаёте ITP, у вас есть номер бага, который вы можете в чейнджлог вписать. Когда вы этот пакет выложите в репозиторий — дело десятое. А даже если его не выложите вообще никогда, то в дебиане уже будет лежать готовый ITP, а процедуру передача или «захвата» сопровождения пакета для таких случаев никто не отменял.
Славная статья, надо будет пофиксить баги :-)
ничего страшного в экспериментальном репозитории нет
использую sid + некоторые пакеты из experimantal, доволен
использую sid + некоторые пакеты из experimantal, доволен
насколько я понял из текста, имелось ввиду не подключение debian «experimental» к другой ветви debian, а к ubuntu — а вот здесь действительно могут быть некоторые проблемы (вроде поломанных зависимостей)
Ну, я писал про подключение experimental к debian'у (мне было лень смотреть, есть ли в ubuntu новая версия пакета, и где — в intrepid, jaunty или еще где), просто если не выставлять никаких флагов по использованию, система, обнаружив новые версии пакетов, обновит всё до experimental, что не есть хорошо :)
Ну теперь можешь загнать файл на PPA (https://help.launchpad.net/Packaging/PPA#Overview) и иметь свой репозитарий.
интересные статьи. но, имхо, стоило всё таки начать с pbuilder'а (а не заканчивать на нём :-), т.к. обычно ни debuild, ни dpkg-buildpackage в чистом виде для сборки пакетов не используются (ибо мусора много в систему тащат в виде ненужных пакетов для удовлетворения зависимостей при сборке); что касается утилит проверки пакета на кошерность, рекомендую(если не сталкивались) обратить внимание на piuparts — проверяет в chroot-окружении, созданном pbuilder'ом, не перезаписывает/удаляет/создаёт/оставляет ли собранный пакет при установке/удалении какие-либо лишние файлы в системе.
И ещё, помимо создания собственного репозитария, думаю, полезной будет заметка наподобие «куда выгружать пакеты, если их не приняли в Ubuntu» и рассказать в ней про использование PPA.
И ещё, помимо создания собственного репозитария, думаю, полезной будет заметка наподобие «куда выгружать пакеты, если их не приняли в Ubuntu» и рассказать в ней про использование PPA.
обычно ни debuild, ни dpkg-buildpackage в чистом виде для сборки пакетов не используются (ибо мусора много в систему тащат в виде ненужных пакетов для удовлетворения зависимостей при сборке)Может я что-то не понимаю, но как можно собрать пакет из исходников не удовлетворив все его зависимости? И как потом использовать его, не установив пакеты от которых он зависит?
Вот как раз для этого и нужно продолжение статьи про pbuilder, чтобы из нее узнать, что этот pbuilder собирает все пакеты в chroot-е и не тащит мусор в рабочую систему.
При установке пакета собранного в chroot'e большая часть этого «мусора» вернется… При этом ее придется скачивать и ставить заново
отнюдь! есть два типа совершенно разных, никак не коррелирующих между собой понятия: зависимости для сборки(компиляции) и зависимости для установки пакета — Build-Depends и Depends поля соответственно, в debian/control. И значения этих полей для пакетов как правило не равны — Build-Depends обычно в разы длиннее и шире; и потом, зачем пользователю, который всего лишь хочет собрать пакет, устанавливать в работающую систему кучу *-dev пакетов на сотню мегабайт с заголовочными файлами, которые а) впоследствии пользователем использоваться в разрабатываемых им программах использоваться не будут; б) не нужны для установки и работы собственно собранного пакета. pbuilder как раз решает все эти проблемы, а мой комментарий лишь к тому был сказан, что обычно с pbuilder'а в различных howto начинают повествование о сборках deb-пакетов, а не заканчивают.
Я посчитал неверным начинать с pbuilder'а. На мой взгляд как раз последовательность довольно логична — сначала рассказать о логике дистрибутива вообще, затем — о том, как именно устроены пакеты и как их собирать и только потом надо рассказывать о создании репозитория, сборке pbuilder'ом и всякой возможной автоматизации.
Как пользователь может собирать пакет загадочным pbuilder'ом, когда еще даже непонятно, как вообще устроен и собирается пакет — а тут еще и добавляется какое-то распаковывание системы в chroot, установка пакетов, потом запаковывание обратно… если так сразу это всё давать, пользователя и испугать может :)
Как пользователь может собирать пакет загадочным pbuilder'ом, когда еще даже непонятно, как вообще устроен и собирается пакет — а тут еще и добавляется какое-то распаковывание системы в chroot, установка пакетов, потом запаковывание обратно… если так сразу это всё давать, пользователя и испугать может :)
Мои мечты о каком-то простом создателе deb-ов развеялись в лучах утреннего солнца.
На самом деле, если вы захотите собрать более «дружелюбный» пакет, вам предстоит куда меньше работы. Просто здесь мне так повезло с предложенным для сборки пакетом, что я смог показать и поиск пакетов в других репозиториях, и ручное патчение исходников :)
Но вообще занятие не самое простое, да. А кому сейчас легко?)
Но вообще занятие не самое простое, да. А кому сейчас легко?)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стать мэинтейнером. Часть третья