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

Я не понимаю. Если в дебиане из реп удалили программу, то при обновлении она у тебя тоже удаляется?

Она хуже работать от этого стала?

Может не собираться с новыми компиляторами и новыми версиями библиотек. Для этого надо будет фиксить. Я помню myrulib пытался собрать, пришлось повозится.

Я не понимаю. Если в дебиане из реп удалили программу, то при обновлении она у тебя тоже удаляется?

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

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

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

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

Если конфликтует, то тоже

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

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

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

Опять же сравнение с виндой. На компе можно одновременно держать и MS Visual Studio 6 (тут правда на 100% не уверен, но 2003-ю точно можно) и современную 2019-го 2022-го года с современными компиляторами.

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

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

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

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

Обычно авторы программы свои установочные скрипты поддерживают. make install, make uninstall и всё такое. А вообще если для тебя это такая прям проблема, то используй один из дистров, которые я тебе перечислил.

Можно отключить, но не нужно.

Я и в gentoo могу несколько версий gcc держать, но если там меняется ABI, то для запуска софтины придётся переключаться на другой тулчейн или колхозить со скриптом запуска и таскать тулчейн с программой - тоже вариант.

Если такая полезная программа не интересна ни самому разработчику, ни кому-то ещё, что до сих пор не пропустил её хотя бы до qt5, то почему ментейнер не может утратить к ней интерес?

Если такая полезная программа не интересна ни самому разработчику, ни кому-то ещё, что до сих пор не пропустил её хотя бы до qt5, то почему ментейнер не может утратить к ней интерес?

На самом деле обычное дело. Не совсем попсовые специальные вещи быстро лишаются авторов. Кто-то однажды написал, поддерживал сколько-то лет, потом потерял интерес и все. Конкретно если про книгодельческий софт, вроде scantailor, то пик интереса был где-то в середине нулевых и заметно угас после 2012-13 примерно года. То есть имеются люди, которым это нужно, но нет какой-то критической массы. Впрочем кто-то ведь озаботился Snap-пакет и форки сделать?

с зависимостями конечно-же цирк..

из недавнего, к gdbm (старый-престарый gnu database manager) чьи-то очумелые ручки прицепили libiconv libintl в зависимости; это к элементарной key-value базе у которой и ключи и значения бинарные и нигде никогда ни на одной платформе она ничего не перекодирует.

гениально, простейшей базе которая нужна (уже «была»,в прошлом уже) при раскрутке системы, требуются файлы с описанием кодировок. А файловой системы-то и нет толком ещё

Ну и используй scantailor-advanced или поройся и поищи патчи для старого. Последняя его версия вышла в 2016 году.

Он не хочет поддержки, он хочет беспроблемной соустановки старых версий на свой страх и риск. Естественно, ПМ из прошлого века ломают об это зубы и отползают обратно на помойку.

nix run nixpkgs/release-21.05#scantailor хочешь ты?

Linux куда-то не туда идет
из реп исчезла нужная программа

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

И ну и что, если программу не обновляют хоть 6, хоть 10 лет?

Это проблема всей индустрии, особенно опенсорса, а не Линукса или Дебиана. Одни люди думают, «если программа не обновлялась полгода, она протухла», другие в ответ бесконечно наяривают версии на своём софте, не предлагая ничего полезного кроме надуманных «фич» и бесконечного рефакторинга и адаптации под более лучшие фреймворки или их версии.

В компаниях с этим получше, я видел много проектов, в которых последние осмысленные коммиты были 5 или даже 10 лет назад, а дальше ничего или мелкий багфиксинг и адаптация документации.

Так он ж и в 22.11 релизе есть.

Я не о конкретике, я о принципе.

В Windows такой проблемы с прикладными программами за редким исключением просто нет.

Есть там тоже проблемы совместимости со старыми программами и довольно частые, мир не идеален. Но такого радикального «выкидывания» технологий там конечно нет.

С каждым выкидыванием какой-то версии Qt отмирает добрая сотня-другая программ, которые никто никогда не обновит на новые мажорные версии.

Причем Qt - как бы изначально линуксовый тулкит.

Да не совсем, в ранние времена он был UNIX-like направленности без акцентрирования внимания на Linux-only, как сегодня.

Но такого радикального «выкидывания» технологий там конечно нет.

Потому, что любая программа, не написанная на winapi, таскает графический тулкит и кучу других библиотек с собой и слинкована с ними же. То же самое можно делать и в linux при желании разработчика создавать подобные сборки. Только размер у них будет соответствующий.

https://github.com/4lex4/scantailor-advanced поддерживает Qt5, вроде.

Просто поставь в свой Debian Nix.

Пытаюсь поставить. Надо же, даже собралось после нескольких пинков из-за недостающих пакетов.

Сейчас в Debian вообще нет в репах Qt4. Ну да, не нужно, зачем, вон и пишут, то программа похоже abandoned, раз 6 лет не обновляется и автор значит вовремя на Qt5 (уже на Qt6 бы и надо) не переписал. https://forums.debian.net/viewtopic.php?t=150861

Там не надо переписывать. Я портировал несколько программ с Qt4 на Qt5 и всё ограничилось правкой имён хидеров в паре мест в каждой. Просто автору насрать стало и он забил.

Короче, либо портируй сам – это не сложно – либо ставь Snap и не ной. Linux не для слабых духом. Порадуйся ещё, что теперь не надо ядро патчить, чтобы твой винмодем заработал.

В Роса все еще в репе есть, в новую платформу переехал тоже.

Тэээкс. Буду повторяться, ну что поделаешь.

В линуксе все прекрасно с зависимостями. В линуксе любой пакет (deb, rpm и т.д.) можно собрать вместе со всеми библиотеками-зависимостями (внезапно) в своем отдельном каталоге (обычно /opt/app_name). При этом никакие зависимости системы сломаны не будут. Для этого есть функциональность RPATH. Это не считая всяких appimage и flatpack.

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

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

И делать это ДОЛЖЕН АВТОР ПРИЛОЖЕНИЯ. И в случае винды и линукс (в случае распространения через ручное скачивание пакета с сайта или через свой личный репозиторий). И вот интересно, если автор этого не сделал, то блин причем здесь линукс, ети вашу мать!

Майнтайнеры дистрибутива точно не будут этим заниматься. У них и так дел хватает.

Собственно для решения твоей проблемы и был придуман flatpak, snap и appimage.

И конкретно эта проблема и решается flatpak’ом или snap’ом. Казалось бы ставь и пользуйся, но нет, это ж ведь так проблема решится, новую выдумывать придётся.

не всем нравится такая снапизация

Не нравится снап, бери флатпак. В отличии от снапа он не запускает кривых демонов, не делает кучу монтирований и в принципе, пока ты не запустил какую-то flatpak-совтину спокойно лежит на диске ни чего не трогая.

Ну и на flathub есть и оригинальный scantailor, и advanced.

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

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

То что уязвимость в ПО является критической ошибкой для дистрибутива и требует исправления. А как это исправлять в неподдерживаемом ПО на неподдерживаемом тулките?

И вот интересно, если автор этого не сделал, то блин причем здесь линукс, ети вашу мать!

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

И эти люди в свое время ругали винду за DLL Hell ...

Если есть желание, всегда можно устроить DLL/so Hell в отдельно взятом контейнере/chroot/namespace/виртуалке.

«Принято» - это не про техническое ограничение. Это про лень. Если бы он хотел, то сделал бы как у какого-нибудь virtualbox.

В Windows такой проблемы с прикладными программами за редким исключением просто нет. Тот же ScanTailor 10-летней давности нормально работает в Win11. Да, с драйверами и системным софтом могут быть приколы, но с прикладным обычно все же нет. 32-битный софт даже 25-летней давности обычно запускается и просто работает

Вы знаете, куда вам идти.

https://launchpad.net/~alex-p/ archive/ubuntu/scantailor/ index

Это не решение ни разу. Дропнут Flatpak этот рантайм (qt4) и всё, тот же самый результат.

Нужны нормальные self-contained установщики или архивы для /opt. Да, весить будет больше. Но это всё ещё не Flatpak, где тебе для одной-двух прог надо тащить рантаймов на несколько гигов.

И делать это ДОЛЖЕН АВТОР ПРИЛОЖЕНИЯ.

Странная логика. Автор мало того, что поделился своим приложением, так ещё и должен опакетить под разные линуксы, винды и маки. Неудивительно, что со временем это надоедает.

Так а виндовые приложения кто собирает и выполняет создание установочного пакета?

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

просто пора признать, что мейнстримные ПМ - кусок того самого

мейнстримные ПМ

Это что за зверь?

пакетные менеджеры

А не мейнстримные всегда носят с собой astral.so на любой случай, а не держат, как и мейнстримные пакетные менеджеры, библиотеки в своём репозитории. Ещё скажи, что у них зависимости не нужно прописывать.

а передергивать не нужно, да? :)

и не стоит мне приписывать слова из своего астрала, понятненько? :))))

ну а для тех кто в танке, не мейнстримные я вообще не стал упоминать, так-как это не путь здорового человека =Р

Всё так.

Причина даже не в самой концепции репозиториев. Концепция-то нормуль. Причина в отсутствии разделения системы и приложений. По сути, Linux это и не система вовсе, а просто свалка софта.

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

Дропнут Flatpak этот рантайм (qt4) и всё, тот же самый результат.

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

У меня проги, зависящие от неподдерживаемых рантаймов прекрасно работают.

Нужны нормальные self-contained установщики или архивы для /opt.

Ну вот есть appimage, не установщик и не архив, но всё в одном файле и переносимо, и весит относительно мало. Только он говно и с переносимостью проблемы. Зато всё как любят виндузятники - сходи на сайт скачай обновление.

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

Дайка подумать, а ведь мы это уже видели, но фанатики должны все яростно отрицать :))))

Ну так эти рантаймы будут по-прежнему доступны для установки без всяких проблем

Хахаха. Очень смешно. В следующей мажорной версии они сломают формат рантаймов, обновят конечно все... поддерживаемые. А неподдерживаемые нет.

Видели где?

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

Хахаха. Очень смешно. В следующей мажорной версии они сломают формат рантаймов

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

просто пора признать, что мейнстримные ПМ - кусок того самого пакетные менеджеры

Аааааааа. Ну уж нет. Пакетные менеджеры - это крутейшая вещь. Чтобы каждый проект не изобретал велосипед в виде свеого мега крутого дизайнерского инсталяка.

Как я уже писал выше: пакет для пакетного менеджера может содержать все требуемые библиотеки зависимости в комплекте.

90-95% системы может находится в основном репозитории, а остальное можно ставить из отдельных репозиториев, если нужны новейшие версии. Ведь при такой схеме утсановленная система занимает в 10 раз меньше свеже установленной винды. Что удобно.

В том, что флатпак перестанет работать со старым форматом.

И вообще, зачем мне в этой цепочке Flatpak нужен?

Несовместимость, второе имя дитстрибутивов. Наверное надёжнее пиcать десктопный софт под wine чем под родные тулкиты :D