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
Description: This is a digitally signed message part
