ха… если бы. Всякие скрипты конфигурирования пост-установки срут и в /etc, и в /var, и демонов прописывают, и чужие конфиги меняют… А потом удаляешь пакет, и оказывается, что какой-нибудь nginx делал include какого-нибудь hhvm, и приехали.
Да не псевдо они, вполне настоящие — как минимум, homebrew. С макпортами плотно не работал, за них сказать не могу. Или почему вы их "псевдо" считаете?
А по поводу решения — может, раз уж Эппл пошла копать в направлении сэндбокса системы, то в 10.12 будет песочница для произвольных приложений? Сейчас песочницы для приложений из стора уже есть, но толку от них.
Ну, чисто теоретически, опять же, можно поверх mach нахреначить гипервизор… Позаворачивать все сисколлы на гипервизор, а оттуда в юзерспейс перекидывать лог действий. Но у меня что-то руки немного опускаются от перспектив подобных извращений — причем я даже не уверен, не работает ли ядро УЖЕ на -1 кольце, или не занимают ли его проги типа Parallels. Вроде ведь как делать цепочки гипервизоров пока нельзя?
А, ну и стоит отдельно отметить, что пакетные менеджеры в Линуксе, например, не ведут учет файлов, которые были созданы после того, как пакет был установлен. Поэтому если пакет не говорит, как именно его деинсталлировать, этот мусор останется висеть.
С программами в Windows та же ситуация — если деинсталлятор предпочтет что-то оставить в системе (какую-то расшаренную библиотеку, или лицензионную информацию) — он их оставит.
Проблема в скриптах пре- и пост-установки, которые могут быть в pkg (ради которых pkg и делают, собственно), причем скрипты не обязательно написаны на shell — это могут быть вообще произвольные бинарники, внутрь которых заглянешь только дизассемблером. Поэтому в общем случае макось не знает, что они творят, и в --files не вносит. Как вариант, решается это виртуализацией процесса установки, чтобы перехватить все операции над ФС и defaults, но в Apple по какой-то причине не стали заморачиваться. Может быть, кто-то заморочится?
Остается, да. Но это не отсутствие механизма удаления библиотек, а отсутствие встроенного пакетного менеджера. Можно, конечно, через pkgutil --files com.teamviewer.teamviewer10 смотреть, что и куда установлено, и удалять руками… А можно пользоваться homebrew, macports и иже с ними, которые более-менее решают эту проблему для софта из репозиториев. Возможно, есть решения и для чистого удаления сторонних .pkg-шек, но я не искал.
В OS X есть две разных семантики библиотек. Одна — .dylib, полностью аналогична .so в Linux, и страдает от тех же проблем.
Вторая — бандлы фреймворков [1][2], в которых используется семантическое версионирование, параллельная установка, динамическая выгрузка (в отличие от dlclose, который на самом деле не обязан ничего выгружать — и не выгружает), и всякое такое.
На маках есть свои проблемы, но dependency hell среди них нет.
Но приложение то слинковано с libfoo.so.1! Нужная либа не находится и приложение не запускается.
Скорее, возникает вопрос "а куда делась so.1, ведь это разные версии API, и пакетный менеджер знает, что so.1 еще используется в таком-то пакете, следовательно, его нельзя удалять и это должна быть side by side установка".
В принципе, несмотря на некоторые ограничения по сравнению с полным semver (например, невозможность указать диапазон допустимых версий для линковки), описанная вами схема вполне рабочая.
Мысли вслух — если у нас есть libfoo.so.1.2.3, то после установки libfoo.so.1.3.0, приложения, которым было важно сохранить точную версию, продолжают использовать libfoo.so.1.2.3, а тем, кому была важна мажорная версия API, будет загружен libfoo.so.1.3.0 через симлинк с libfoo.so.1. Все выглядит достаточно логичным, от менеджера пакетов требуется только понимать, какая версия используется в каком бинарнике и не удалять старые версии, если они где-то используются явно.
Но теперь я не понимаю, почему в принципе идут разговоры "о ужас, в linux есть dependency hell! кошмарный dll hell, как в windows!"? Если множество разных версий библиотек могут спокойно уживаться вместе — в чем в принципе тогда были предпосылки для создания snap-пакетов?
Не, суть как раз не в том, чтобы ставить их из репозитория — я думаю скорее о деинсталляции пиратского самодельного софта. А так — дропнул pkg на "конвертилку", а оно конвертит в формулу и ставит в /usr/local/, вне зависимости от лицензии и происхождения этого pkg. А потом удаляет оттуда же.
Я сейчас задам глупый, нубский вопрос, но тем не менее прошу дать на него умный ответ. Тут очень многие пишут о dependency hell, перезаписи системных библиотек разными версиями и других неудобствах, которые влечет за собой нынешняя система зависимостей.
Я хотел уточнить — я правильно понимаю, что нынешний подход динамического линковщика к поиску зависимых библиотек абсолютнейше не включает в себя semver? Другими словами, если в /usr/lib/ есть libfoo-1.0.4.so, libfoo-1.9.so и libfoo-2.0-rc1.so, а программе нужен libfoo-1.so, то ей не загрузят libfoo-1.9.so автоматически? Или, например, если нужен libfoo-1.0.3.so, то не будет предложен libfoo-1.0.4.so?
Если так, то, может, решать проблему нужно с другого конца?
Возможно, пылесос с водяным фильтром бы был лучше? Когда они метут, большая часть пыли улетает назад от ветра, а, похоже, что в этой мелкой пыли как раз весь сок.
Спасибо, гражданин, отличная формулировка ;)
ха… если бы. Всякие скрипты конфигурирования пост-установки срут и в /etc, и в /var, и демонов прописывают, и чужие конфиги меняют… А потом удаляешь пакет, и оказывается, что какой-нибудь nginx делал include какого-нибудь hhvm, и приехали.
Да не псевдо они, вполне настоящие — как минимум, homebrew. С макпортами плотно не работал, за них сказать не могу. Или почему вы их "псевдо" считаете?
А по поводу решения — может, раз уж Эппл пошла копать в направлении сэндбокса системы, то в 10.12 будет песочница для произвольных приложений? Сейчас песочницы для приложений из стора уже есть, но толку от них.
Ну, чисто теоретически, опять же, можно поверх mach нахреначить гипервизор… Позаворачивать все сисколлы на гипервизор, а оттуда в юзерспейс перекидывать лог действий. Но у меня что-то руки немного опускаются от перспектив подобных извращений — причем я даже не уверен, не работает ли ядро УЖЕ на -1 кольце, или не занимают ли его проги типа Parallels. Вроде ведь как делать цепочки гипервизоров пока нельзя?
А, ну и стоит отдельно отметить, что пакетные менеджеры в Линуксе, например, не ведут учет файлов, которые были созданы после того, как пакет был установлен. Поэтому если пакет не говорит, как именно его деинсталлировать, этот мусор останется висеть.
С программами в Windows та же ситуация — если деинсталлятор предпочтет что-то оставить в системе (какую-то расшаренную библиотеку, или лицензионную информацию) — он их оставит.
Маки в этом плане не исключение.
Проблема в скриптах пре- и пост-установки, которые могут быть в pkg (ради которых pkg и делают, собственно), причем скрипты не обязательно написаны на shell — это могут быть вообще произвольные бинарники, внутрь которых заглянешь только дизассемблером. Поэтому в общем случае макось не знает, что они творят, и в --files не вносит. Как вариант, решается это виртуализацией процесса установки, чтобы перехватить все операции над ФС и defaults, но в Apple по какой-то причине не стали заморачиваться. Может быть, кто-то заморочится?
Остается, да. Но это не отсутствие механизма удаления библиотек, а отсутствие встроенного пакетного менеджера. Можно, конечно, через
pkgutil --files com.teamviewer.teamviewer10смотреть, что и куда установлено, и удалять руками… А можно пользоваться homebrew, macports и иже с ними, которые более-менее решают эту проблему для софта из репозиториев. Возможно, есть решения и для чистого удаления сторонних .pkg-шек, но я не искал.Нет, с чего вы взяли?
В OS X есть две разных семантики библиотек. Одна — .dylib, полностью аналогична .so в Linux, и страдает от тех же проблем.
Вторая — бандлы фреймворков [1][2], в которых используется семантическое версионирование, параллельная установка, динамическая выгрузка (в отличие от
dlclose, который на самом деле не обязан ничего выгружать — и не выгружает), и всякое такое.На маках есть свои проблемы, но dependency hell среди них нет.
Вроде как на современных процессорах уже много лет вместо
int 80hиспользуютсяsysenterиsyscall.Скорее, возникает вопрос "а куда делась so.1, ведь это разные версии API, и пакетный менеджер знает, что so.1 еще используется в таком-то пакете, следовательно, его нельзя удалять и это должна быть side by side установка".
В принципе, несмотря на некоторые ограничения по сравнению с полным semver (например, невозможность указать диапазон допустимых версий для линковки), описанная вами схема вполне рабочая.
Мысли вслух — если у нас есть
libfoo.so.1.2.3, то после установкиlibfoo.so.1.3.0, приложения, которым было важно сохранить точную версию, продолжают использоватьlibfoo.so.1.2.3, а тем, кому была важна мажорная версия API, будет загруженlibfoo.so.1.3.0через симлинк сlibfoo.so.1. Все выглядит достаточно логичным, от менеджера пакетов требуется только понимать, какая версия используется в каком бинарнике и не удалять старые версии, если они где-то используются явно.Но теперь я не понимаю, почему в принципе идут разговоры "о ужас, в linux есть dependency hell! кошмарный dll hell, как в windows!"? Если множество разных версий библиотек могут спокойно уживаться вместе — в чем в принципе тогда были предпосылки для создания snap-пакетов?
Эх, если бы директории можно было хардлинкать...
Не, суть как раз не в том, чтобы ставить их из репозитория — я думаю скорее о деинсталляции
пиратскогосамодельного софта. А так — дропнул pkg на "конвертилку", а оно конвертит в формулу и ставит в /usr/local/, вне зависимости от лицензии и происхождения этого pkg. А потом удаляет оттуда же.Просто кто-то таки должен взять ситуацию в руки и сделать конвертер из pkg в формулы homebrew в один клик.
Я сейчас задам глупый, нубский вопрос, но тем не менее прошу дать на него умный ответ. Тут очень многие пишут о dependency hell, перезаписи системных библиотек разными версиями и других неудобствах, которые влечет за собой нынешняя система зависимостей.
Я хотел уточнить — я правильно понимаю, что нынешний подход динамического линковщика к поиску зависимых библиотек абсолютнейше не включает в себя semver? Другими словами, если в
/usr/lib/естьlibfoo-1.0.4.so,libfoo-1.9.soиlibfoo-2.0-rc1.so, а программе нуженlibfoo-1.so, то ей не загрузятlibfoo-1.9.soавтоматически? Или, например, если нуженlibfoo-1.0.3.so, то не будет предложенlibfoo-1.0.4.so?Если так, то, может, решать проблему нужно с другого конца?