Re: Я хочу попробовать себя мейтенером.

2 views
Skip to first unread message

Maksim Dmitrichenko

unread,
Jan 28, 2022, 1:20:04 PM1/28/22
to
"Если надо объяснять, то не надо объяснять" =)

Рано вы, дружище, взялись за шашку. Читать вам надо mentors.debian.net до просветления.

В целом тут помощи тоже сложно сыскать в этом вопросе [1]

[1] https://lists.debian.org/debian-russian/2021/12/msg00023.html

пт, 28 янв. 2022 г. в 12:48, Leonid <gribano...@mail.ru>:
Здравствуйте.

Я хочу попробовать быть сопроводителем пакетов debian.

Подскажите пожалуйста, какие пакеты стоит попробовать пособирать для
начала.

Какие требования к сборке (каким компилятором, с какими опциями)?

Обязательно ли делать кросс-компиляцию для всех архитектур или можно
собирать только под удобные?


В общем, прошу подскать :)

Спасибо.




--
With best regards
  Maksim Dmitrichenko

Nicholas Guriev

unread,
Jan 29, 2022, 4:50:03 AM1/29/22
to
Добрый день!

Раз вы до сих пор не получили отклика из этого списка, то вам придётся
заполнить RFS report по-английски и отправить его в BTS.

https://mentors.debian.net/sponsors/rfs-howto/prometheus-cpp/

Учтите, что на mentors.d.n загруженные пакеты хранятся ограниченное
количество времени, а потом безвозвратно удаляются. Кажется, всего месяц
или два хранятся.

Возможно, вам стоит обратиться непосредственно к DD, который создал
проект <https://salsa.debian.org/debian/prometheus-cpp>.

signature.asc

Nicholas Guriev

unread,
Jan 29, 2022, 4:50:03 AM1/29/22
to
On Пт, 2022-01-28 at 14:11 +0500, Leonid wrote:
> Я хочу попробовать быть сопроводителем пакетов 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 (и
подобных) сценариев. Если потребуется, могу рассказать про них отдельно.

signature.asc

Жанибек Нагашыбай

unread,
Feb 6, 2022, 3:20:03 AM2/6/22
to
В Sun, 06 Feb 2022 11:43:16 +0500
Leonid . <cpp...@ya.ru> пишет:
 
> Могу ли я поставлять скрипты в пакете не только для systemd, но еще и
> для sysVinit, openrc, runit?

Конечно, это даже приветствуется.

Nicholas Guriev

unread,
Feb 6, 2022, 3:30:04 AM2/6/22
to
On Вс, 2022-02-06 at 11:43 +0500, Leonid . wrote:
> Ну я имел в виду, что собирать я должен "системным" 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.

signature.asc
Reply all
Reply to author
Forward
0 new messages