Где делать универсальную сборку

Скорее нужно ориентироваться на минимальную версию Убунту. Она самая популярная и всякие мятки уже на ее основе. Если тулза для терминала, то можно через docker распространять, а те кому очень надо, пусть компилируют

Если честно, меня удивило количество советов про докер и прочие контейнеры. Я-то хочу сделать пакет максимально ненавязчивым для пользователя, а тут прямо наоборот. Тем, кто осилил докер и готов тащить его в десктопную систему, и qmake && make сложным не будет.

Моё видение решения на момент написания ОП было сделать AppImage, при этом не тащить в него кутешные либы под одну программу, а собрать её статикой, это гораздо меньше места занимает. Остался вот только вопрос с libc и прочей низкоуровщиной, вот по нему я и хотел посоветоваться.

P.S. А 18-я убунта действительно постарше бастера будет, подумаю об этом…

если ты делаешь сборку своего СПО проекта, то она не нужна так как есть исходники

Далеко не все готовы с этими исходниками разбираться.

У меня сама процедура сборки достаточно простая, но и с ней, как показывает практика, возникают вопросы, поскольку разные библиотеки и тулзы для сборки могут лежать (в зависимости от дистрибутива) в пакетах с совершенно разными и не всегда предсказуемыми названиями.

Ну и есть люди, которых сама необходимость сборки отпугивает. Они могут быть первоклассными врачами, учителями, пекарями, архитекторами — но требовать от них вникания в системы сборки не очень разумно. Говорить им «линукс не для вас» тоже неправильно.

У меня сама процедура сборки достаточно простая, но и с ней, как показывает практика, возникают вопросы, поскольку разные библиотеки и тулзы для сборки могут лежать (в зависимости от дистрибутива) в пакетах с совершенно разными и не всегда предсказуемыми названиями.

Даже если это так (а я с 20летним опытом сборки всего и вся не представляю что это за тулзы могут быть такие), ты серьёзно считаешь что собрать эти названия будет сложнее чем разбираться с построением блоба который хотя бы на 75% этих дистрибутивов будет работать?

Ну и есть люди, которых сама необходимость сборки отпугивает

Так им не надо ничего собирать. Ты модератор и не знаешь о существовании репозиториев и мантейнеров? Или ты считаешь что твоя софтина настолько уникальна что нужна миллионам пользователей, которые не смогут её собрать, но при этом не найдёт ни одного мантейнера который её опакетит? Тут обычно советуют подойти ближе к писсуару, а если более конструктивно, то потратить время и силы на улучшение софтины, а не пердолинг с блобами.

Просто собери статику (все либы вместе, да хоть всё в один бинарник) — лишь бы оно запускалось и работало.

Так ему не выложить в дистры надо, а просто пользователям дать нормальную программу.

Да и много утилит до внедрения в дистры распространяются в виде бинарников (и даже после внедрения в дистры всё равно поставляются в виде бинарников).

Уж если ты 20 годиков пользуешься, то и это знать должен (хотя ты как бака-гайдзин разговариваешь, приврал небось про 20 лет, 0,75-2,15 года скорее всего).

По glibc нет проблем)

Собирай в виртуалке с древней убунтой, запускай с виртуалке с арчем. Вот тебе и тест. У них будут максимально разные как номера версий, так и раскладка файловых путей. Остальное в процессе вылезет.

мы собираем под ubuntu 18.04

Это самый древний из живых линуксов

RHEL-7 — 2014

RHEL-6 — 2010

Так ему не выложить в дистры надо, а просто пользователям дать нормальную программу.

Это одно и тоже, а вот блоб - противоположность нормальности.

Да и много утилит до внедрения в дистры распространяются в виде бинарников (и даже после внедрения в дистры всё равно поставляются в виде бинарников).

А много не распространяются в виде бинарников никогда.

мя́тки или мятки́?

А много не распространяются в виде бинарников никогда.

Сакраментальное «100% пользователей интернета пользуются интернетом».

Конечно же большинство софта в мире распространяется в виде бинарей.

Это одно и тоже, а вот блоб - противоположность нормальности.

Вот напишешь что это признак «бед с башкой» и соевый лор может и замодерировать за такое — вот как быть в такой ситуации?

Конечно же большинство софта в мире распространяется в виде бинарей.

Мы говорим об СПО. Конечно же большинство распространяется в виде исходников и родных для дистрибутивов пакетов из них собранных.

Тут я сугубо про десктоп и пользователей десктопа.

Подавляющая доля СПО котороя в итоге устанавливается к пользователям на ПК также приходит к ним в виде блобов, а не пакетов с зависимостями или исходниками.

На условной «винде» пользователей СПО больше, чем всех «линуксоидов» и инсталляций «линукса».

СПО это не линукс и не обязательно на нём работает.
Зависимости пакетов это не СПО.
Блоб не значит плохо.
Исходники не значит хорошо.

(Да-да, даже зная это, ты всё равно игнорируешь эти аспекты)

На условной «винде» пользователей СПО больше, чем всех «линуксоидов» и инсталляций «линукса».

На винде даже нет пакетного репозитория, о чём тут говорить? Ты запутался. Речь, напомню, о выборе пользователей. Они, при наличии родного репозитория, никакие блобы ставить не будут

Нет, если вопрос ставить как «подо что делать блоб», то ответом будет винда, естественно. Но вопрос стоит «как делать блоб под линукс». Ответ по прежнему - никак не делать.

Зависимости пакетов это не СПО.
Блоб не значит плохо.
Исходники не значит хорошо.
(Да-да, даже зная это, ты всё равно игнорируешь эти аспекты)

Это пустые сотрясения воздуха, не только не доказанные, но даже не обоснованные.

Они,

«Они» сейчас с нами, в этой комнате?
«Они» часто вам говорят, что они бы сделали?

Как в твоей голове это всё уживается с очевидной реальностью ТСа?

RHEL-7 — 2014

RHEL-6 — 2010

я сказал: «из живых» линуксов. Так то я могу достать диск с надписью RedHat 5, а это не этот ваш смешной новодел, а всё таки середина 90-х.

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

В отличие от твоего Red Hat 5, это совершенно живые дистры. За них деньги платят, а за это обновления безопасности выпускаются и прочая поддержка. Если у тебя на них не хватает денег, завидуй тише =)

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

Ты почему-то думаешь, что чужой коммерческий успех как-то влияет на тебя и начинаешь защищать RHEL6. Примерно такое же поведение, как если бы изнасилованная девушка начала восхищаться тем, какой крутой мачо её насильник и говорить подружкам «да у тебя просто мужика нормального не было».

Нормальный, здоровый, не травмированный человек, который ещё и не имеет коррупционной доли, не может в 2023-м году называть RHEL6 живым дистрибутивом.

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

Я работаю в Red Hat над обновлениями безопасности RHEL, в том числе RHEL 6.

Нормальный, здоровый, не травмированный человек, который ещё и не имеет коррупционной доли, не может в 2023-м году называть RHEL6 живым дистрибутивом.

Есть чёткое определение мертвизны — неподдерживаемость вообще. Называть мёртвым поддерживаемое, пусть и ограниченно, может только демагог.

Поэтому собсно и во флатпаках glibc нет и быть не может

Не делай людям смешно таким бредом плиз.

но при этом не найдёт ни одного мантейнера который её опакетит

Сама по себе — не найдёт. Тут либо мне надо его поискать, либо кроме разработки, заниматься ещё и пиаром. Собственно, пиаром всё равно надо заниматься, да. Хотя, если честно, то лучше

потратить время и силы на улучшение софтины, а не

…на социальную деятельность по её популяризации, да.

И одного мейнтейнера тут явно не хватит, тут нужно минимум по одному на дистрибутив. Хотя бы из мейнстримовых.

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

оно не поддерживаемое

Глухое отрицание тебя не красит.

А я могу в 2023 году легально и бесплатно скачать RHEL 6 или хотя бы 7? В то, что поддержка клиентов осуществляется, я верю. Но мне нужно для разработки СПО-продукта, на котором сам я денег не зарабатываю, покупать для этого целый RHEL — перебор, имхо.

А я могу в 2023 году легально

Да

и бесплатно скачать RHEL 6

Не думаю, что он есть в бесплатном варианте, 6 в достаточно глубокой фазе старости. Возможно придётся раскапывать CentOS.

или хотя бы 7?

Можешь. На https://developers.redhat.com/products/rhel/download вижу 7, 8 и 9.

Тут собирают и опакечивают одним скриптом под разные системы.

А я могу в 2023 году легально и бесплатно скачать RHEL

учитывая, что RedHat грубо кинул клиентов в России, поувольнял пачку людей (скорее всего смешной защищальщик копролитов тоже на очереди) — непонятно как ты это планируешь сделать.

Сама по себе — не найдёт. Тут либо мне надо его поискать, либо кроме разработки, заниматься ещё и пиаром. Собственно, пиаром всё равно надо заниматься, да. Хотя, если честно, то лучше

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

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

…на социальную деятельность по её популяризации, да.

Ну как тебе сказать. Для полезного приложения деятельность по его популяризации заключается в единственном анонсе в каком-нибудь популярном месте типа реддита, и для него даже писать ничего не надо, потому что это всё уже записано в README.md. После этого пользователи сами растаскивают его по хакерньюсам, твиттерам и другим местам. На себе проверено.

Если ты адекватный автор, то твоя стратегия - пилить исходники и всё. Полезное приложение расползётся само, бесполезное ты сам не должен хотеть распространять.

Ну как тебе сказать. ТС ведь не об этом спрашивал. И даже если в каком-то дистрибьютиве опакетят приложение, почему бы при релизе не выложить свежие пакеты не дожидаясь мэйнтеров?

Потому что это портатит время и не будет работать.

В sqlitestudio так:

...
  matrix:
    binary_compatibility:
      - "glibc_2.23"  # Ubuntu 16.04
      - "glibc_2.27"  # Ubuntu 18.04
      #- "glibc_2.31"  # Ubuntu 20.04, Debian 11
    qt_version:
      - "5.15.2"
      - "5.15.9"
    exclude:
      - binary_compatibility: glibc_2.23
	qt_version: "5.15.2"
      - binary_compatibility: glibc_2.27
	qt_version: "5.15.9"
    include:
      - binary_compatibility: glibc_2.23
	container: ghcr.io/${{ github.repository }}/gha-build-runner-xenial
	icu_version_short: 66
      - binary_compatibility: glibc_2.27
	container: ghcr.io/${{ github.repository }}/gha-build-runner-bionic
	icu_version_short: 60
...

У всех, кому надо, работает, а у тебя не будет, ну ок

Чистый Debian с минимальным окружением, поддерживающий сборку с GLIBC >=2.24. Прослеживается обратная совместимость до версии 2.32. Еще желательно собирать с поддержкой C формата 2011 года.

Вот тебе, пожалуйста, из последних новостей: сил редхэтовских мейнтейнеров уже не хватает для такого must have, как LibreOffice, что уж там говорить про сотни небольших утилит от разных авторов…

сил редхэтовских мейнтейнеров уже не хватает для такого must have, как LibreOffice

Ну это такой себе показатель - от коммерческих паразитов вполне ожидаемо скинуть свою работу на других, а денег брать столько же. Это не показывает никакую проблему традиционных пакетов, почему-то у десятков маргинальных дистрибутивов с куда меньшими ресурсами, вплоть до таких которые поддерживает всего один человек, сил поддерживать пакет либры хватает:

https://repology.org/project/libreoffice/versions

что уж там говорить про сотни небольших утилит от разных авторов…

Ну не стыдно нести такой бред? Для подавляющей массы небольших утилит никаких пакетов кроме дистрибутивных нет и не будет.

со стареньким glibc.

а при чем тут вообще glibc? оно же с ним линкуется внешне... а встраиваемая часть рантайма вроде бы никогда не менялась и соответственно не зависит от версии glibс.

мы компилируемся с gtk 3.10, но часть фич работать не будет; чтобы работали все, нужна сборка с gtk 3.20

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

только если в пакете указано прямо зависимость или внутри идет ручная линковка через ldopen или как енто там происходит (никогда не делал подобную дичь).

ldopen

dlopen?

никогда не делал подобную дичь

Ну почему сразу дичь. Да, dlopen требует дополнительных действий, но он же в некоторых случаях даёт дополнительную гибкость. Например, позволяет организовать систему плагинов. Или делать какие-то зависимости нежёсткими. Например, предположим, что я пишу GUI для распознавания текстов. На входе могут быть как файлы, так и бумажные документы. Для последнего случая можно пытаться динамически грузить SANE, если это не получается — выдавать пользователю осмысленное сообщение и корректно работать только с файлами. Зачем тащить SANE жёсткой зависимостью, если на машине сканера нет…

ну фиг знает — но это делает код непереносимым и с мороками как раз — но даже тут можно же подгружать не версионированную либу же. Суть моя была именно про захардкоженную версионность glibc.