Затем что появился стабильный vasyan-app1.0.2(3, 4 и т.д.). Было бы логичнее, если бы nix и guix(раз они заявляют что dependency hell не пройдет) или же разворачивали все необходимое в один каталог с приложением, или же для общих файлов был один каталог типа /store/share-files

Пусть цветут все цветы

Затем что появился стабильный vasyan-app1.0.2(3, 4 и т.д.).

Это ни в коей мере не делает необходимым удаление /store/asfasfas90f-vasyan-app1.0.1, потому что vasyan-app1.0.2 будет стоять в /store/dfkjdfkdj-vasyan-app1.0.2 и никаким образом не будет вмешиваться в работу vasyan-app1.0.1 и всех кто от него зависит. Если parashad зависит от vasyan-app, то parashad собирается с указанием на конкретную версию vasyan-app (например asfasfas90f-vasyan-app1.0.1). Если после этого поставить vasyan-app1.0.2, то можно пересобрать parashad и получить

/store/cviciass-parashad
/store/ibiasdki-parashad

Оба будут работоспособными. Если у нас не прописано, что мы обязательно хотим сохранить тот parashad, который лежит в cviciass, то сборщик мусора удалит старый vasyan-app и parashad, потому что они оба не нужны. Если же parashad не заработал с новым vasyan-app, то можно прописать, что нам нужна именно эта старая версия parashad, тогда сборщик мусора не удалит старый parashad и старый vasyan-app. Guix гарантирует что parashad будет работать так же как и раньше, а не хуже или лучше.

Было бы логичнее, если бы nix и guix(раз они заявляют что dependency hell не пройдет) или же разворачивали все необходимое в один каталог с приложением, или же для общих файлов был один каталог типа /store/share-files

Ничуть не логичнее.

Ничуть не логичнее.

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

PC-BSD (операционная система на базе FreeBSD) справляется с dependency hell путём размещения пакетов и зависимостей в самодостаточные директории-контейнеры, избегая таким образом повреждения системных библиотек при обновлениях или иных их изменениях. Система PC-BSD использует «PBI» (Push Button Installer) как основной пакетный менеджер.

Почему-то думал что в NixOS и GuixSD сделали так же. В убунте тоже будут пилить что-то подобное.

Не лучше

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

Нет, не лучше.

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

путём размещения пакетов и зависимостей в самодостаточные директории-контейнеры

То есть в каждую директорию кладётся и программа и все зависимости? Это же практически статическая линковка.

Во-первых, от такого разделения нет никакой пользы.

Обоснуй подробнее.

То есть в каждую директорию кладётся и программа и все зависимости? Это же практически статическая линковка.

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

И все таки почему в NixOS и GuixSD нету ада зависимостей, библиотеки то используют общие?

P.S. В профиле у тебя написано, что ты ипользуешь NixOS.

Обоснование

Обоснуй подробнее.

Если бы от этого была бы какая-то польза, то её можно было бы заметить. А раз её нельзя заметить, значит пользы нет.

Один и тот же пакет может содержать в себе и собственные бинарники и библиотеки, которыми он пользуется сам, но разрешает пользоваться и другим. Стоит ли его помещать в /shared ? А если его библиотеками фактически никто кроме него не пользуется, то стоит ли перемещать в /shared или оставить в /store?

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

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

Guix во многом решает те же проблемы что и контейнеры, но делает это лучше и экономнее.

А если его библиотеками фактически никто кроме него не пользуется, то стоит ли перемещать в /shared или оставить в /store?

Тоже об этом думал, тоже правильно. А если нам например очень необходимо удалить /store/sdgfsdgsdg-vasyanapp1.0.1, бибилиотеки которого использует /store/dgsdgsdgkl-jigurda12.0, vasyanapp таки удалится? Если да, то как тогда с библиолеками, которые использует jigurda12.0?

целыми виртуалками, потому что только так удалось разрулить зависимости

Хоть даже так, потому что этот зоопарк уже всех достал.

Guix во многом решает те же проблемы что и контейнеры, но делает это лучше и экономнее.

Почему его тогда или NixOS мало кто использует?

Поправил

В профиле у тебя написано, что ты ипользуешь NixOS.

Спасибо за напоминание, поправил.

Сборщик джигурды

А если нам например очень необходимо удалить /store/sdgfsdgsdg-vasyanapp1.0.1, бибилиотеки которого использует /store/dgsdgsdgkl-jigurda12.0, vasyanapp таки удалится? Если да, то как тогда с библиолеками, которые использует jigurda12.0?

Что значит «нам очень необходимо удалить vasyan-app1.0.1»? Зачем нам его удалять? Если вы хотите пользоваться vasyan-app1.0.2, то просто поставьте vasyan-app1.0.2 и пользуйтесь, vasyan-app1.0.1 от этого не сломается. И jigurda12.0 тоже не сломается, потому что продолжит исползовать библиотеки из vasyan-app1.0.1.

Почему его тогда или GuixSD мало кто использует?

Инертность мышления, раз. Сложности с портированием ПО низкого качества и всяких грязных трюков, два. Все привыкли собирать deb'ы для Ubunt'ы хер знает как, не считаясь с зависимостями, потому что ряд пакетов «есть всегда» и т.п. В общем от Ubunt'ы и прочих ждут определённого поведения не задумываясь почему оно должно быть таким и может ли оно в каких-то случаях быть другим. Guix этого не позволяет, хочешь поставить программу (новую, написав для неё scm) — аккуратно вписывай все зависимости, не впишешь — не соберётся. Но вот если однажды вписал, то соберётся всегда, в отличие от Ubunt'ы, где после неудачной установки находишь на StackOverflow решение в духе «нужно почистить кеш, снести libvasyan-ssl и поставить libvasyan-tls, после этого повторить установку».

Что значит «нам очень необходимо удалить vasyan-app1.0.1»? Зачем нам его удалять?

Необходимо и все, мало ли. Удалили vasyanapp1.0.1 и сборщик мусора все почистил и нету больше его, как быть тогда с jigurda12.0, который использует либу vasyanapp1.0.1 ?

Все привыкли собирать deb'ы для Ubunt'ы хер знает как, не считаясь с зависимостями, потому что ряд пакетов «есть всегда» и т.п.

Не только убунта, но и почти все остальные дистры. А убунта переходит на snappy, где эту проблему решат(надеюсь). Во всех дистрах давно уже пора так сделать.

В общем от Ubunt'ы и прочих ждут определённого поведения не задумываясь почему оно должно быть таким и может ли оно в каких-то случаях быть другим

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

Разборщик джигурды

Необходимо и все, мало ли. Удалили vasyanapp1.0.1 и сборщик мусора все почистил и нету больше его, как быть тогда с jigurda12.0, который использует либу vasyanapp1.0.1 ?

Знач так, не «удалили», а пометили «этот пакет мне, пользователю, больше не нужен». Если этот пакет больше никому не нужен, то сборщик мусора его удалит. Но мы знаем, что jigurda12.0 использует vasyan-app1.0.1, поэтому не удалит.

Если же запустить sudo rm -rf /store/19sksd2-vasyan-app1.0.1, то чего же ты хочешь от Guix'а?

А убунта переходит на snappy, где эту проблему решат(надеюсь).

snap это практически setup.exe. Будут в Ubunt'е пакеты в /Program\ Files/. Дожили. Ubuntu это лучший Windows.

Нежелательно беспокоиться

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

Не понял, как это разработчики могут не беспокоиться о состоянии ОС, в которой их софт будет работать?

Package: vasyan-app
Depends: ruby

И посрать, что работает только на ruby-2, а на ruby-1.9.3 не работает.

Не понял, как это разработчики могут не беспокоиться о состоянии ОС, в которой их софт будет работать?

Потому что это не их забота.

Работа-работа, перейди на Федота

Потому что это не их забота.

Мне кажется мы с вами не понимаем друг друга, говорим о разных вещах.

Я выше привёл пример control-файла вымышленного пакета. Как вы считаете, разработчик vasyan-app ведёт себя нормально, или это его обязанность прописать Depends: ruby (>= 2.0)?

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

Manyamiroque

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

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

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

snap это практически setup.exe

И чем же это плохо? Поясни, только без фанатизма.

В такое случае ведроидовский apk тоже аналог setup.exe

А вы тут при чём вообще?