Re: Я хочу попробовать себя мейтенером.
Maksim Dmitrichenko
[1] https://lists.debian.org/debian-russian/2021/12/msg00023.html
Здравствуйте.
Я хочу попробовать быть сопроводителем пакетов debian.
Подскажите пожалуйста, какие пакеты стоит попробовать пособирать для
начала.
Какие требования к сборке (каким компилятором, с какими опциями)?
Обязательно ли делать кросс-компиляцию для всех архитектур или можно
собирать только под удобные?
В общем, прошу подскать :)
Спасибо.
Maksim Dmitrichenko
Nicholas Guriev
Раз вы до сих пор не получили отклика из этого списка, то вам придётся
заполнить RFS report по-английски и отправить его в BTS.
https://mentors.debian.net/sponsors/rfs-howto/prometheus-cpp/
Учтите, что на mentors.d.n загруженные пакеты хранятся ограниченное
количество времени, а потом безвозвратно удаляются. Кажется, всего месяц
или два хранятся.
Возможно, вам стоит обратиться непосредственно к DD, который создал
проект <https://salsa.debian.org/debian/prometheus-cpp>.
Nicholas Guriev
> Я хочу попробовать быть сопроводителем пакетов debian.
Отличное начинание! 🙌
> Подскажите пожалуйста, какие пакеты стоит попробовать пособирать для
> начала.
Посмотрите PDF-презентацию о пакетировании из пакета packaging-tutorial.
Ознакомьтесь с Debian Policy Manual (есть только английский вариант).
Много полезных ссылок вы найдёте на <https://wiki.debian.org/Packaging>.
Если уже примерно разбираетесь как создавать пакеты, то в поисках идей
взгляните на список WNPP <https://www.debian.org/devel/wnpp/>. Есть сайт
с удобным поиском <https://wnpp.debian.net/>.
После того, как ваш новый пакет с исходным кодом будет готов (файл .dsc
и связанные), загрузите его на <https://mentors.debian.net/> и откройте
RFS запрос в псевдопакете sponsorship-requests. Можно воспользоваться
шаблоном, предлагаемым на mentors.d.n сайте.
> Какие требования к сборке (каким компилятором, с какими опциями)?
Особых требований нет. Вполне можно положиться на upstream, какие опции
они используют. Компилятор, конечно же, зависит от языка
программирования, на котором написана программа. Среди build-essential
пакетов есть компиляторы C и C++ из пакета src:gcc-defaults. Все другие
компиляторы надо указывать явно в поле Build-Depends.
За флаги сборки отвечает утилита dpkg-buildflags(1). От сборочной
системы, применяемой в пакете, требуется лишь учитывать переменные
окружения CFLAGS, CXXFLAGS, DFLAGS и подобные.
> Обязательно ли делать кросс-компиляцию для всех архитектур или можно
> собирать только под удобные?
В большинстве случаев достаточно убедиться, что программа вообще
компилируется хотя бы на вашем компьютере. Все пакеты в Debian "нативно"
собираются специальной сетью сборочных машин, buildd
<https://www.debian.org/devel/buildd/>. Возможность кросскомпиляции не
обязательна, но желательна. К счастью для простых программ APT и Dpkg
способны самостоятельно разобраться с кросскомпиляцией прозрачно для
сопровождающего.
Из-за кросскомпиляции в файле d/control появляются некоторые нюансы,
связанные с кодогенерацией или запуском Python/Perl/Ruby/PHP (и
подобных) сценариев. Если потребуется, могу рассказать про них отдельно.
Жанибек Нагашыбай
Leonid . <cpp...@ya.ru> пишет:
> Могу ли я поставлять скрипты в пакете не только для systemd, но еще и
> для sysVinit, openrc, runit?
Конечно, это даже приветствуется.
Nicholas Guriev
> Ну я имел в виду, что собирать я должен "системным" GCC, а не clang или
> чем-нибудь подобным?
> (Просто некоторые проекты рекомендуют использовать конкретный
> компилятор.)
Сперва стоит попробовать собрать компилятором по умолчанию в Debian -
GCC. Если всё-таки требуется какая-то особая функциональность Clang,
скажем -fblocks, то придётся задействовать его. Надо учитывать, что у
LLVM в Debian более низкий уровень поддержки по сравнению с дефолтным
инструментарием. Например, на днях я столкнулся с тем, что Clang не
способен собрать рабочие исполняемые файлы для IBM System z из кода на
C++ с исключениями. Впрочем, это уже другая история, но если ваш пакет
не соберётся для одной из выпускающих архитектур[1], это заблокирует его
переход в тестируемый и стабильный выпуски.
[1]: https://www.debian.org/ports/#released
Чтобы выбрать конкретный компилятор, пропишите зависимость в d/control.
Build-Depends-Arch: clang | c-compiler
А в d/rules как один из вариантов установите переменную окружения.
export CC ?= clang
Не прописывайте жёстко конкретную версию компилятора, потому что это
создаст проблемы при обновлении.
> Могу ли я поставлять скрипты в пакете не только для systemd, но еще и
> для sysVinit, openrc, runit?
Да, конечно! Если они работоспособные. Тогда Devuan сможет напрямую
использовать ваш пакет, без доп. изменений.
Раздел 9.3 руководства по политике Debian[2] настаивает (написано should
have), чтобы они назывались также как и сервисы для systemd. Также есть
условие, чтобы сервис назывался бы также как и сам пакет.
[2]: https://www.debian.org/doc/debian-policy/ch-opersys.html#s-services-intro
> А про флаги... То есть я выбираю поддержку чего выкинуть и чего
> включить?
> Нет какого-нибудь регламента?
О какой-то кодифицированной спецификации или регламенте мне не известно.
Общее соглашение таково, что сопровождающий сам решает, какой функционал
полезен в Debian, ориентируясь на мнение пользователей. Моё мнение:
имеет смысл включать по умолчанию максимально неконфликтующую
функциональность. Можно рассмотреть возможность сборки нескольких
двоичных пакетов за раз из одного исходника, включая разные функции в
разных пакетах. В пример такого подхода можно привести Vim или Qt.
Вынужден отметить, что в таком случае есть сложности при использовании
рекомендуемого инструмента dh(1) из состава Debhelper.