Как я люблю зависимости и вот это вот всё

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

Ты не следишь за нитью. У меня была совсем другая проблема, и проблема ТС с его Qt 4 тут вообще ни при чём. Напротив, у меня была «мёртвая платформа», то бишь CentOS 7, а девелопер компилировал на какой-то более-менее новой Ubuntu. В итоге – типичная линуксовая параша с несоответствием GLIBC, вместо запуска приложения.

Сырцы закрыты? Если сырцы открыты, то что мешает пересобрать и не получать проблемы с GLIBC?

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

Я начал с того, что им и не нужно. Почему мы вдруг опять к этому вернулись? oO

Сырцы открыты, говорю же – тратил время и компилировал вместе с зависимостями, вместо того чтобы заниматься более привлекательными (в моём понимании, а не в понимании красноглазиков/пердолей) делами.

Как я люблю зависимости и вот это вот всё (комментарий)

То есть, если производитель хочет быть уверен, что его прога будет работать так, как им задумано - ему надо собирать прогу самому. В винде так и устроено всё. В Линуксе дистрибутивы суют в программы свои костыли с непредсказуемым результатом.

Сырцы открыты, говорю же – тратил время и компилировал вместе с зависимостями, вместо того чтобы заниматься более привлекательными (в моём понимании, а не в понимании красноглазиков/пердолей) делами.

Попроси автора собрать flatpak. Лулз в том, что Linux как OS не существует. Есть RHEL, есть Ubuntu, есть Gentoo и все это именно что разные OS, потому что базовые компоненты у всех разных версий. Есть перцы, который вообще с musl'ом в качестве stdlib гоняют.

Отсюда и все проблемы с совместимостью.

То есть, если производитель хочет быть уверен, что его прога будет работать так, как им задумано - ему надо собирать прогу самому. В винде так и устроено всё. В Линуксе дистрибутивы суют в программы свои костыли с непредсказуемым результатом.

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

Попроси автора собрать flatpak.

А может Linux-сообществу стоит наконец взять яйца в руки и грозным рывком решить эту проблему с GLIBC? Вместо всех этих «сходи», «попроси», «поплачь на форуме», «скомпилируй сам», «помолись», «чё как ни джентушник».

Кстати GLIBC тот ещё кусок глючного кала, который может сегфолтиться даже с хелловорлдов, как недавно выяснили на ЛОРе.

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

А может Linux-сообществу стоит наконец взять яйца в руки и грозным рывком решить эту проблему с GLIBC? Вместо всех этих «сходи», «попроси», «поплачь на форуме», «скомпилируй сам», «помолись», «чё как ни джентушник».

У Linux-сообщества до сих пор нет единой точки входа — своей OS. У них есть разные OS, которые управляются разными людьми. Поэтому ожидать совместимость по ABI — крайне наивное занятие.

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

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

Лулз в том, что Linux как OS не существует.

А не ты ли в соседнем треде плакался на счёт того, что в экосистеме дистров Linux нет нормального системного API (+ прикладных фреймворков) и ПО должно угрёбищно мимикрировать то под один тулкит, то под другой.

ITT ты плачешь в обратную сторону.

У них есть разные OS

Ну и пусть все эти разные ОС лежат в отдельных подмножествах файловой иерархии, в своих неймспейсах. Под управлением нормального пакетного менеджера, а не очередного апта.

А не ты ли в соседнем треде плакался на счёт того, что в экосистеме дистров Linux нет нормального системного API (+ прикладных фреймворков) и ПО должно угрёбищно мимикрировать то под один тулкит, то под другой.

Ну тулкит-то можно один сделать, верно? К двум-то пришли, можно и до одного свести попробовать.

ITT ты плачешь в обратную сторону.

Пажжи, бомбит у вас, а плачу я? Странная логика.

Ну и пусть все эти разные ОС лежат в отдельных подмножествах файловой иерархии, в своих неймспейсах. Под управлением нормального пакетного менеджера, а не очередного апта.

Сделай это!

Надо ядро патчить!

Надо ядро патчить!

Зачем? Там уже есть namespace'ы.

Как я люблю зависимости и вот это вот всё (комментарий)

Эээ... зачем тебе хардлинки на каталоги? Просто копируй их и все.

зачем тебе хардлинки на каталоги?

Чтобы в системе не было 20 копий одной и той же зависимости.

Чтобы в системе не было 20 копий одной и той же зависимости.

Эээ... а зачем для этого нужно хардлинки на каталоги? И да, посмотри уже на nix. Там даже KDE готовят

Ну тулкит-то можно один сделать, верно? К двум-то пришли, можно и до одного свести попробовать.

Один тулкит, один пакетный менеджер, один wm…

Один тулкит, один пакетный менеджер, один wm…

В чем смысл разных пакетных менджеров или wm'ов я понимаю. В чем смысла двух одинаково раздутых тулкитов — нет. Если бы один из них был бы супер-пупер такой unixway-секурный-легкий-yadda-yadda я бы понял. Но они оба одинаково раздутые.

а зачем для этого нужно хардлинки на каталоги?

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

Плюсую, GTK давно пора закопать. Местечковое уродливое поделие, которое постоянно ломают.

Амароком не пользуюсь уже лет 6, а послений ~год - счастливый пользователь облачного сервиса для прослушивания музла.
Но с твоим вбросом относительно либ согласен.

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

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

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

Какого? Я пытаюсь пользоваться yandex.music и google.music, но там нет много того, что мне бы хотелось, чтобы там было.

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

Всё это огрехи и ошибки проектирования мира Linux. Вместо того чтобы исправлять UNIX-вейное дерьмо, все тянут эту заразу, преподносят недостатки как фичи и воздают им славу. Вон один попытался разрушить накопившиеся говно и костыли из bash-лапши, так вой и стоны копротивленцев до сих пор слышны.

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

Пажжи, а зачем разраб подготавливает бинарный пакет своего ПО? Сделал софтину, сделал тарболл, написал документацию — все, дальше мейнтейнеры сами разберутся.

Например,
XScreensaver может быть удалён из Debian
Началось — пакет weboob заявлен к удалению из Дебиан из-за названия

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

Шта?

$ cd /tmp/nixos-not-invented-here
$ mkdir -p programs/bar-0.1/files
$ touch programs/bar-0.1/files/libbar1.so
$ touch programs/bar-0.1/files/libbar2.so
$ mkdir -p programs/foo-1.0/{files,deps}
$ mkdir -p programs/foo-1.0/deps/bar
$ cd programs/foo-1.0/deps
$ ln -s ../../bar-0.1/files bar

Усе, готово. Единственное, что нужно сделать — запретить приложению менять файлы другого приложения, но это запросто решается другими путями.

P.S. Серьезно, ты хочешь nixos, его уже придумали за тебя.

И? Если кому-то припрет, он сделает свой deb-репозиторий.

И? Если кому-то припрет, он сделает свой deb-репозиторий.

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

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

Доступность софта Петяна зависит от того, сделает ли Васян репозиторий, да. Важные вещи вроде libreoffice из дебиана почему-то не удаляют.

Смотри, допустим, есть lib1, appA и appB, оба app зависят от lib1. Допустим, ты кидаешь в каталоги appA и appB симлинки на каталог с lib1. Потом lib1 обновляется на lib1.2 и appA нормально работает, а appB отваливается. Это если в имени каталога lib1 не фигурирует версия. А если фигурирует - отваливаются обе app, потому что симлинки начинают вести в никуда.

Допустим, lib1 не обновляется, а удаляется - обе app превращаются в тыкву с битыми симлинками в своих каталогах.

Доступность софта Петяна зависит от того, сделает ли Васян репозиторий, да.

В данной цепочке Васян очевидно лишний.

Важные вещи вроде libreoffice из дебиана почему-то не удаляют.

Это просто петух не успел клюнуть. Была такая важная вещь, называется ffmpeg, под видом которой продавливали libav.

ты хочешь nixos

Покажи как там системная иерархия устроена.

Смотри, допустим, есть lib1, appA и appB, оба app зависят от lib1. Допустим, ты кидаешь в каталоги appA и appB симлинки на каталог с lib1. Потом lib1 обновляется на lib1.2 и appA нормально работает, а appB отваливается. Это если в имени каталога lib1 не фигурирует версия. А если фигурирует - отваливаются обе app, потому что симлинки начинают вести в никуда.

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

Покажи как там системная иерархия устроена.

Залезь да посмотри, документация на сайте проекта есть.

Это просто петух не успел клюнуть. Была такая важная вещь, называется ffmpeg, под видом которой продавливали libav.

Я помню. В итоге, ЕМНИП, никто, кроме авторов libav, ffmpeg и дистростроителей разницы не заметил.

При таком подходе у тебя должно быть установлено несколько версий lib1

А да, я забыл, что ещё нужна ФС с copy-on-write))

Хотя, наверное, можно и без неё, но это усложнит пакетник.

Я помню. В итоге никто, кроме авторов libav, ffmpeg и дистростроителей разницу не заметил, насколько я помню.

Ага.
Конфликт между FFmpeg и Libav мешает разработке проектов

В этом году в состав FFmpeg было добавлено множество фильтров, в основном аудио. Libav проявил интерес к расширению набора своих фильтров, но вместо использования наработок FFmpeg просто взялся улучшать API. Как считает Бош, это приводило к нарушению совместимости API несколько раз.

А да, я забыл, что ещё нужна ФС с copy-on-write))

Не нужна, симлинки атомарны.

Конфликт между FFmpeg и Libav мешает разработке проектов

То есть у пользователей все ок было, я правильно понимаю? :)

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

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

То есть у пользователей все ок было, я правильно понимаю? :)

Т.е. множество авторов libav, ffmpeg и дистростроителей ты уже расширил до разработчиков сторонних проектов?
https://superuser.com/questions/507386/why-would-i-choose-libav-over-ffmpeg-o...

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

У тебя, по хорошему, зависимость вообще не должна обновляться. То есть ты не обновляешь файлы в директории bar-1.0/files, ты ставишь рядом bar-1.0.1/files и во всех программах меняешь симлинки. И только тогда, когда никто больше не использует bar-1.0, ты её удаляешь.

Короче, читай про nix.

P.S.

NixOS основан на диспетчере пакетов Nix, который хранит все пакеты отдельно друг от друга в хранилище пакетов.

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

Следствием этого является то, что NixOS не соответствует стандарту иерархии файловой системы. Единственными исключениями являются symlink /bin/sh для версии bash в менеджере пакетов Nix (например: /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/) и, в то время как у NixOS есть каталог /etc для хранения файлов конфигурации всей системы, большинство файлов в этом каталоге являются символическими ссылками на сгенерированные файлы в /nix/store, такие как /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета.

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

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

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