Все же с библиотеками и зависимостями Linux куда-то не туда идет

Всё можно статически собрать.

И что, статический бинарь будет работать если изменится libc и ядро? Спешу тебя разочаровать.

И что, статический бинарь будет работать если изменится libc и ядро? Спешу тебя разочаровать.

Ядро как правило держит обратную совместимость в юзерспейсе. А libc при статической линковке вкомпилена в бинарь, так что если собирать на старом ядре, а запускать на более новом, то в подавляющем большинстве случаев всё будет работать.

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

если изменится libc и ядро

Конечно будет. Системные вызовы не ломают.

ну вот теперь пускай пихают в снап или флэтпак.. дольше проживёт..

Scantailor и форки есть в сторонних репозиториях.

И чо? Вот даже официальный мануал есть https://doc.qt.io/Boot2Qt-5.15/qtee-static-linking.html Всё можно статически собрать.

И то. Ты попробуй собрать. Вот в винде например. Еще бывает куча вспомогательных файлов вместе с приложением: какие-то 3д модели, музыка, модели нейронок, конфиги и херова гора всего разного. Это все равно нужно тянуть с собой, одним файлом сложное приложение не отделается.

И что будет с загружаемыми плагинами? Да, там есть мануал, как их собирать статически, но это еще одна дополнительная задача. Опять же, попробуй сделать это сначала. По моему опыту многолетних сборок Qt скажу так: там есть возможные ошибки и подводные камни. И заморочиться бывает нужно сильно. А если у тебя кроссплтформенный проект под Linux/Mac/Win то это еще нужно сделать три раза. И постоянно повторять, мы же хотим использовать актуальную версию Qt? Поэтому в крупных проектах НАДЕЖНЕЕ использовать тот вид дистрибуции фреймворка или либы, который изначально планировал разработчик этого фреймворка.

Кроме того, в случае Qt остается вопрос с лицензией. Ты помнишь, что в случае статической линковки нужно приобретать платную версию?

А еще есть либы, которые в процессе работы тоже загружают другие либы через dlopen / LoadLibrary и нет там воможности при сборке указать, чтобы все, что они загружают, тоже статически линковалось. И что тогда делать? Вручную править third_party проекты?

Здравствуйте.

В очередной раз обнаружил, что из реп исчезла нужная программа. ScanTailor на этот раз.

> dnf.search scantailor
Last metadata expiration check: 
========= Name Exactly Matched: scantailor ===========
scantailor.x86_64 : An interactive post-processing tool for scanned pages

> flatpak search scantailor --columns=name,version,application
Name                           Version             Application ID
ScanTailor Advanced            v1.0.16             com.github._4lex4.ScanTailor-Advanced
Scan Tailor                    0.9.12.1            org.scantailor.ScanTailor

По сути, Linux это и не система вовсе, а просто свалка софта.

Жил в общаге с человеком, который экономил место на HDD, удаляя лишние DLL из C:\Windows\System32\

Кроме того, в случае Qt остается вопрос с лицензией. Ты помнишь, что в случае статической линковки нужно приобретать платную версию?

Если приложение под GPL- совместимой лицензией, ничего платить не нужно.

По сути, Linux это и не система вовсе, а просто свалка софта.

В отличие от винды, ага :-) и от мака, :-) там так не свалка.

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

В пятидесятый раз повторяю: в Linux можно в пакеты deb/rpm и т.п. складвать ВСЕ библиотеки зависимости (как в винде). И некоторые проекты так и делают. Но для большинства пакетов, которые устанавливаются при установке системы это не нужно, чтобы только что установленная система не занимала 50Gb на диске.

Если приложение под GPL- совместимой лицензией, ничего платить не нужно.

Я знаю, кэп. Но я не про GPL.

https://flathub.org/apps/details/com.github._4lex4.ScanTailor-Advanced

https://flathub.org/apps/details/org.scantailor.ScanTailor

/thread

в Linux можно в пакеты deb/rpm и т.п. складвать ВСЕ библиотеки зависимости (как в винде)

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

Да, там есть мануал, как их собирать статически, но это еще одна дополнительная задача

Не надо там ничего отдельно собирать, если это не твои собственные плагины.

еще есть либы, которые в процессе работы тоже загружают другие либы через dlopen / LoadLibrary

Есть, тот самый 1% программ, о котором я упомянул. Есть разные решения для этого, как из всё-таки слинковать статически, или забандлить в бинарь как ресурсы.

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

Причина даже не в самой концепции репозиториев.

Лишний раз похвалю разработчиков QT.
Они переняли все лучшее в архитектуре GUI Windows и добавили свое.

ИМХО разумный подход.

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

Я не проверял. Но давай рассуждать. Этот аргумент про «у меня в винде программа X работает Y лет и еще проработает U лет». Так ты ведь и не обновляешь не винду это время до новых версий. Так и Linux поставь в такие условия: поставь дистрибутив, поставь самодостаточный пакет и не обновляй ни то, ни другое сколько хочешь. Что-то мне подсказывает, что так может проработать, пока жесткий диск не посыпется.

централизованных магазинов приложений

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

Все же с библиотеками и зависимостями Linux куда-то не туда идет
Сейчас в Debian вообще нет в репах Qt4

Это личные трудности Дебиана + лень маинтайнеров!
Лично у меня на Федоре-36 доступен и scantailor из стандартного репозитория rpm + все версии qt одновременно - и qt3 и qt4 и qt5 и qt6. qt3-4-5 у меня установлены со всеми средствами разработки и используются постоянно (в разных проектах).

Вовсе необязательно размещать пакет на флатхабе.

Тут показывали проги из win95, которые работают на win10 и поддерживают всякие фишки типа hidpi

Вовсе необязательно размещать пакет на флатхабе.

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

Согласен.

Ну а чё, автору (авторам) же делать нефиг как переписывать на новый тулкит.

Кто мешает тебе переписать её на новые культи? Или взять дистр где есть старые культи?

Я вот тоже не понимаю, почему мейнтейнеров дистрибутива должно волновать что-то, что не подтягивается зависимостями типа lsb-* plasma-minmal, gnome*-minimal и т.п.

Нужны какие-то приложения и новые библиотеки для него, которых нет в системе? Хорошо – вот тебе вольер для приложений, вот вольер для библиотек. Нужны какие-то старые библиотеки, которые уже выкинули – вот тебе музей для старых библиотек. Отдельно от системы. Надо обновить систему – обновляй, того, чего ты сам понаустанавливал это вообще не касается; всё, что отличается от нового релиза и без чего не обойтись идёт в вышеобозначенные места. Мне с дивана видится так.

Бывает так, что одно приложение уже выкинуто из состава дистрибутива, а для другого в данном дистрибутиве ещё нет нужных компонентов. Да, частично спасает flatpak и appimage, но потом в какой-то момент обнаруживаешь у себя в хомяке директорию flatpak размером в 7ГБ и в корневом размером 20ГБ.

Конечно будет. Системные вызовы не ломают.

Ну да, именно поэтому у нас пакеты libc5, libc6. И представляешь, сломать можно даже не трогая системные вызовы. Достаточно изменить реализацию, вспомни про memcpy() и memmove().

Дебианопроблемы

dnf.search

Что за нафиг? Когда у dnf появился такой синтаксис?

В данном случае это личные трудности ТСа. Для дебиана есть репозитории с этим ПО и его форками. Есть куча способов установить его, и даже указали причину почему его нет в репе дебиана, это ПО не уникально и до него выкидывалось из дебиана.

Есть, тот самый 1% программ, о котором я упомянул. Есть разные решения для этого, как из всё-таки слинковать статически, или забандлить в бинарь как ресурсы.

Да сколько бы не было. Заниматься натягиванием совы на глобус. Ради чего непонятно. Спортивный интерес только.

Тут показывали проги из win95, которые работают на win10 и поддерживают всякие фишки типа hidpi

Дай пожалуйста ссылку, хочу проверить, как они работают.

И что это доказывает? Что в линуксе невозможно собрать пакет со всеми зависимостями?

И можно поискать программы из времен Win 95, которые не работают корреткно на Win 10 /11. Что это доказывает?

Что в Линуксе ты таких примеров не найдёшь. И что для линуксового ПО выбыть из репозиториев = перестать работать на Линуксах, в 95% случаев.

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

Боже мой. Ну услышьте вы меня. В пакет deb/rpm можно ложить все требуемые библиотеки. Никаких зависимостей от более новых/старых версий таких же библиотек, которые уже есть в системе, не будет.

Если либа не общая для всей системы, то она не расшаривается в памяти с другими программами (т.к. её больше никто не использует)

Что с того? Теряешь сколько-то мегабайт ОЗУ и места на диске, зато в принципе не имеешь описанных в первом посте проблем. Хочется минимализма и экономии каждого мегабайта - терпи.

Ты не в ту сторону воюешь. Не надо триггериться на отдельные слова.

Поэтому такие аналогии как «Хвост вертит собакой» к данному случаю отношения не имеют.

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

Что в Линуксе ты таких примеров не найдёшь.

Примеры найдешь везде.

И что для линуксового ПО выбыть из репозиториев = перестать работать на Линуксах, в 95% случаев.

Да епсель твою налево. Ну не пихай ты свое приложение в стандартный реп. Распростроняй через вручную скачиваемый deb/rpm пакет со своего сайта. И складируй в пакет все либы, которые хочешь.

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

Распростроняй через вручную скачиваемый deb/rpm пакет со своего сайта. И складируй в пакет все либы, которые хочешь.

И делай это регулярно, а то работать перестанет 😄

Все же с библиотеками и зависимостями Linux куда-то не туда идет

Может быть так?

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

Нет, это абсолютно точно описывает положение дел в линуксе

Нет. Хотябы потому что эникеи не занимаются сборкой пакетов. Как минимум.

И делай это регулярно, а то работать перестанет.

Как минимум в рамках одного релиза не перестанет. Для Ubuntu это 5 лет. Потом соберешь еще версию. Это так часто да?

И можно ссылку на программы из Win 98, которые работают в Win 10?

Как минимум в рамках одного релиза не перестанет. Для Ubuntu это 5 лет. Потом соберешь еще версию.

Ну вот о чём и речь

Пожалуй да, эти джамшуты ментейнеры не тянут даже на эникеев.

А может и вообще не перестанет, тут уж нужно проверять. Например проект, в котором я участвую работает одновременно и в Ubuntu 20.04 и в 22.04.

Так а в чем проблема? Раз в пять лет сделать пакет?

И ты ссылку на программы из Win 98, которые работают в Win 10 даешь или нет?

1C 7.7 (в ней правда разработчики на «дядю» не надеялись).

Проблема в постоянном отвале софта по вине системы.

В винде ты можешь для решения своей задачи откопать какую-нибудь самописную софтину 15-летней давности, и она будет работать. В Линуксах такое практически невозможно. Сколько софта умерло вместе с дропом qt3 и gtk2?

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

Да покажи мне такую. Сколько просить можно.

В Линуксах такое практически невозможно. Сколько софта умерло вместе с дропом qt3 и gtk2?

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

Да это не от системы зависит.

Ага, разработчик должен этим заниматься, лол. Напиши программу, постоянно чини её от отвала в Линуксах, огребай хейт от людей, у которых всё-таки отвалилось. Вместо того, чтобы один раз сделать софтину и греться мыслью, что она и через 15 лет кому-то пригодится.

Идиотия полнейшая.

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