Как правильно запаковать проект?

Ну, если есть какая-то билд-система, то есть и возможность опакетить программу. Многие держат в репе не сами готовые пакеты, а сборочные скрипты, например. Они заводят в репе каталог packaging и туда кидают EBUILD-ы, PKGBUILD-ы, SlackBuild-ы и так далее. А майнтайнеры пакетов в дистрибутивах уже адаптируют это добро под реалии дистрибутивов. Главное, чтобы пути к файлам не были захардкожены, иначе майнтайнерам придётся патчить исходники. В последнее время ещё AppImage, snap и Docker добавились.

Там CMake и я без проблем могу сделать при помощи его CPack базовые DEB и RPM как минимум. Вопрос в том, что с ними делать дальше и как, например, обычно решается проблема с разными версиями зависимостей на разных версиях дистрибутивах. Поддерживать это самому в одно рыло кажется проблематичным.

> куда их лучше класть (в стандартные репы фиг прорвёшься)

Скачиваемые deb и rpm пакеты покроют большую часть современных дистров.

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

Учитывай, что у всех разные shared библиотеки. Используй musl или glibc минимальной целевой версии.

Общая площадка в каждом дистре своя. В арче такой является aur.archlinux.org.

> где [баги реальных пользователей] брать в мире open-source?

Добавь в man секцию BUGS с ссылкой на заведение багов.

Проси в README проекта заводить баги. Добавь секцию с благодарностью за помощь.

Заведи шаблон GitHub issue.

Некоторые при запуске утилиты пишут сообщение с просьбой о поддержке. Сообщение можно убрать через env-флаг или не выводить его при повторном запуске. Самое главное здесь не быть навязчивым.

Ну, например, на Github можно постить пакеты из тегов – держать базовые RPM и Deb, а для всех прочих – тарболы *.tar.*z? (и в бинарниках, и в виде сырцов), и например, PKGBUILD в AUR. Этого более чем достаточно, а остальные сваяют себе пакеты сами (естественно, инструкцию по сборке приложить понадобится).

Про deb:

Разные версии зависимостей проблема только если у них имена файлов сменились или почему-то обратная совместимость сломана, а так в списке указывается не точная версия а минимальная или диапазон. Если речь про библиотеки, то слом совместимости случается при смене мажорной версии (libc.so.5 vs libc.so.6) - надо выпускать пакеты для каждого из вариантов который хочешь поддерживать. Компилировать в chroot-ах соответствующих например дебианов. Я например сделал chroot-ы для дебианов с 8 по 12, каждый в i386 и amd64 варианте, и скрипт с помощью которого можно выполнить в них нужные команды по списку. Но реально (именно в моём случае, у тебя может быть по-другому) для совместимых пакетов понадобились debian 8 и debian 10, т.к. скомпилированное в deb8 успешно работает и в 9, а скомпилированное в deb10 - в 11 и 12.

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

> как, например, обычно решается проблема с разными версиями зависимостей на разных версиях дистрибутивах

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

Разделяемые библиотеки можно положить прям в свой deb/rpm и зависеть от них. За исключением glibc.

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

Где-то может и так, но в дебиане (если ты не делал экзотических настроек) они должны быть не просто в репозитории дебиана, а в репозитории той версии дебиана что у тебя установлена. То есть обычно есть только одна версия, редко две.

Да там по сути кроме glibc ничего в самой либе и не используется. ICU4C (опционально), и мелкие либы для XML/JSON/YAML, используемые CLI-тулом и тоже отключаемые. Но при этом, например, версию CMake пришлось прямо подбирать, чтобы проект собирался одновременно на всех системах хотя бы на один релиз минус от текущего актуального, и это оказалась нетривиальная задача. Вот подобные неочевидные эффекты меня больше всего и беспокоят, но вероятно стоит просто попробовать и посмотреть, на что жаловаться начнут

Понял, спасибо большое. Это выглядит проще, чем мне казалось

> кроме glibc ничего в самой либе и не используется

Собирай со старым glibc. Он обратно-совместим (старый код будет работать на новой версии), но не прямо-совместим (новый код не будет работать на старых версиях).

От glibc там не требуется ничего особенного, а для части удобств уже есть обёртки (делались для Windows), так что это не должно быть проблемой. Насколько старую версию имеет смысл выбирать - просто посмотреть версии в основных дистрибутивах минус один-два стабильных релиза и выбрать наименьшую?

Ну, как минимум, можно ориентироваться на oldstable и даже oldoldstable релизы Debian, но при этом поддерживать сборку на testing (но не на unstable). И вообще, в целом, обратную совместимость ломают чаще в ядре, чем в юзерспейсе.

Там CMake и я без проблем могу сделать при помощи его CPack базовые DEB и RPM

Ты не с того конца заходишь. Тебе не надо делать бинарные дистрибутивы. Тебе надо докинуть в исходники минимум для создания пакетов из исходников.

Как лучше сделать пакеты для Linux

Создать в дереве исходников файлы, необходимые для сборки пакета. Для дебьяна есть пара простыней, как это делать:

https://www.debian.org/doc/manuals/maint-guide/index.ru.html
https://wiki.debian.org/HowToPackageForDebian

Но проще поискать похожий проект на CMake и скопировать из него директорию debian. Есть утилиты типа dh_make, которые создадут готовый шаблон пакета под debian, но я не уверен, что это облегчит задачу - там тонны не нужны файлов.

Прожиточный минимум всего несколько файлов:

changelog
control
copyright
rules

Проще скопировать из похожего на твой и подправить под свой проект.

куда их лучше класть

С такой директорией тебе бинарники можно вообще не класть - есть хороший шанс, что пакет включат сами разрабы дистра. Можешь кинуть объявление в подходящий список рассылки.

Но если очень хочется именно бинарники - то лучше прогуглить их создание с помощью CI. В твоём случае - на github actions, пакты будут в релизах на самом гитхаб.

и как, например, обычно решается проблема с разными версиями зависимостей на разных версиях дистрибутивах.

Не решай. Сделай одну рабочую конфигурацию под текущий стабильный релиз и ничего не делай больше. Если у тебя нет требований по минорным версиям - тебе это не надо этим заморачиваться.

Да, если с github actions есть сложности, то у SUSE есть открытый сервис по сборке пакетов в т.ч. под дебьян:

https://en.opensuse.org/openSUSE:Build_Service_Debian_builds

С этого же сервиса идёт раздача готовых бинарников.

О, спасибо огромное за ссылки на мануалы!

Но если очень хочется именно бинарники - то лучше прогуглить их создание с помощью CI. В твоём случае - на github actions, пакты будут в релизах на самом гитхаб.

Да, у меня уже стоит эта задачка в планах.

Не решай. Сделай одну рабочую конфигурацию под текущий стабильный релиз и ничего не делай больше. Если у тебя нет требований по минорным версиям - тебе это не надо этим заморачиваться.

Не, там реально совершенно базовый glibc и ничего больше не нужно. По зависимостям тулзы посмотрю, но тоже особых сюрпризов быть не должно.

Можешь кинуть объявление в подходящий список рассылки.

А что, так можно было?

Можешь кинуть объявление в подходящий список рассылки.

А что, так можно было?

Есть списочек https://lists.debian.org/debian-devel/ , где как раз решают, какие пакеты добавить / удалить в дистрибутиве. Если у тебя есть рабочее ПО под debian, ты заинтересован в том, чтобы программа работала и готов в случае чего помочь разрабам дебьяна, а сама программа достаточно интересна - то шансы высоки, что её могут включить в дистрибутив.

Звучит отлично! Я в основном Debian и использую, любимый дистрибутив :)

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

Не кажется.

Именно поэтому придумали флатпак. Но он только для графических утилит, т.е. не подходит. Есть снап, но он популярности не снискал. Остается AppImage в качестве универсального источника.

Дальше надо смотреть, сколько и каких зависимостей. Но в целом все уже сказали: базовый deb и rpm пакеты - должно быть достаточно. (И Арч, и Арч). Ракеты лежат на сайте, в гите.

Дальше можно смотреть в сторону своего репозитория, но это то, чего хотелось бы избежать, как я понимаю.

Умеет экспортировать дампы в XML, JSON и YAML и даже анонимизировать их при сохранении

Звучит круто! Мне нравится!

Спасибо! Я к 0.6.0 ещё немного баги постабилизирую, должно хорошо выйти. А заодно и модуль ядра прикручу для sysfs. Ну это типа неделя-две, я сейчас без работы сижу, поэтому всё равно заняться больше нечем :)

Дальше надо смотреть, сколько и каких зависимостей. Но в целом все уже сказали: базовый deb и rpm пакеты - должно быть достаточно. (И Арч, и Арч). Ракеты лежат на сайте, в гите.

Зависимостей там 4 штуки - icu4c, libxml, libyaml и libyajl, все отключаемые билд-флагами - но, правда, вместе с локализацией и поддержкой соответствующих форматов.

Я для релизов на гитхабе взял за основу https://github.com/ra3xdh/qucs_s/.github/workflows/deploy.yml

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

libxml, libyaml, libyajl

Тут проблемы быть не должно. Вряд ли там ломали обратную совместимость. Так что можно будет указать весьма широкий диапазон версий.

icu4c

Впервые слышу. Ничего не скажу.

все отключаемые билд-флагами

КМК убирать точно не стоит.

Спасибо! Посмотрю обязательно

Модуль ядра в этой истории выглядит избыточным. Делай userland либу, а к ней уже биндинги к прикладным языкам (python, go, rust). А для shell-скриптов можно в cli сделать вывод в машиночитаемый формат типа xml или json

Модуль ядра удобен, если нужно из скриптов что-то вытаскивать, у меня есть реальные кейсы из прода, где это нужно. Userland-либа уже есть, биндинги будут - к Python уже начал делать, Go/Rust будут позже. Машиночитаемый формат конечно хорошо, но там портянка на сервере может быть и сотня килобайт так-то, ради одно параметра на каждом вызове скрипта её дёргать и парсить через условный jq - тупит будет всё.

А тащить в ядро парсинг всего этого странного стало быть не смущает? А потом еще и иметь сложности поддержки из-за stable api non sense.txt

А в чём проблема в случае опционального модуля, если он нужен для конкретной задачи? Тем более Парсинг там декларативный, описывается как набор правил для state machine поверх универсального движка. Не говоря уже о том, что даже в основном коде ядра из-за особенностей железа (а SMBIOS по сути прямо из них следует) ничуть не меньше чуднОго.

Я сделал вот так: https://gitlab.com/pekmop1024/nvme-wear

Все работает на бесплатном тарифе гитлаба, CI собирает docker image и пакеты для альмы, дебиана и арчика, хранится соответственно в регистри гитлаба и пакетном сторадже гитлаба. Уверен, то же самое можно сделать и на гитхабе. Я использую гитлаб, потому что эта репа - публичное зеркало внутреннего моего гитлаба, а писать и Gitlab CI и Github Actions мне лень.

Спасибо большое! Тоже посмотрю обязательно

Для Ubuntu, Debian делать релизы пакетов. Для всяких арчей сами разберутся, на aur зальют

естественно, инструкцию по сборке приложить понадобится

Там CMake, у него "инструкция" — две команды.

@sdnvx, можешь зайти в IRC/Matrix/whatever самых популярных дистров (Ubuntu, Arch, вот это всё) и "отрекламироваться", только смотри чтобы за спамера не приняли.
Когда оно будет в популярных дистрах, остальные растащат себе уже без твоего непосредственного участия.

Если у тебя CI/CD прикручено, можешь собранные бинари/пакеты в релизах выкладывать аттачами.

Если соберёшь под FreeBSD, готов хоть сейчас потыкать.

Когда будет больше свободного времени (и если не забуду), сделаю "порт".

Там CMake, у него «инструкция» — две команды

Там еще скрипт внутре, а вроде в дистрах способ сборки через запуск скрипта не приветствуется.
И еще этот скрипт требует git, и не собирается на релизных тарболах. Но это мелочи уже.

CI/CD прикручено, оно автоматом в GitHub собирается на Linux/FreeBSD/NetBSD/macOS/Windows с тестами, санитайзерами и коверейджем. Прикрутить сборку базовых deb/rpm/exe пакетов туда - в целом не проблема.

А соберу! :)

скрипт внутре

Ну вот скрипт меня немного смутил, но его ж не обязательно юзать как он есть, просто берёшь логику из него и натягиваешь на реалии дистрибутива.

Мне, например, его на pmake придётся переписывать (потому я и не кинулся "портировать" сразу).

Ну я собрал просто чтобы утилиту посмотреть. Мне не понравилось то что в утилиту встроена прокрутка, и нельзя просто пльзоваться скроллом в терминале.Наверное, не буду это пакетить.