https://www.opennet.me/openforum/vsluhforumID3/77309.html После восьми лет разработки увидел свет (http://permalink.gmane.org/gmane.comp.file-systems.zero-install.devel/4186) первый релиз децентрализованной, независящей от дистрибутива, системы инсталляции/запуска приложений Zero Install 1.0 (http://0install.net). Новая версия не несет в себе каких-либо серьезных изменений, кроме исправления двух незначительных ошибок, но знаменует собой окончательную стабилизацию метаданных, кода и форматов, используемых для распространения приложений.<br><br><br>Основная идея и отличие Zero Install от других систем инсталляции приложений заключается в том, что он дает пользователям возможность запуска приложений с сайта разработчика/дистрибьютора без их фактический инсталляции. Установив на машину Zero Install пользователю останется только указать адрес файла-описания нужного приложения и оно со всеми зависимостями будет загружено и запущено в полностью автоматическом режиме. Все приложения кэшируются в домашнем каталоге пользователя и проверяются на обновления во...<br><br>URL: http://permali https://www.opennet.me/openforum/vsluhforumID3/77309.html#55 Wed, 01 Jun 2011 13:18:49 GMT &gt; Из возможности положить в "одинаковые" libA.so.X немного разным образом собранный код, <br>&gt; например. При этом без дополнительного анализа ABI формализация зависимостей вдруг <br>&gt; может оказаться на практике неполной: soname не определяет ключи компиляции как <br>&gt; минимум, да и вообще ABI (некоторые апстримы не заморачиваются поднимать soname, <br>&gt; чуточку поломав ABI).<br>&gt; Алексей Турбин в альте эту проблему анализировал и решил, поскольку централизованных репозиториев <br>&gt; она (ессно) тоже касается, но там по крайней мере возможно централизованно <br>&gt; же и ловить такие крайние случаи.<br><br>А в Zero Install невозможно? Возможно. Более того, там такие проблемы возникают редко (я, вот, не сталкивался) и уже разрешимы как минимум путём отката на более раннюю версию библиотеки. Причём, версию можно выбрать для каждого приложения, для каждого пользователя.<br><br>А как в Альте решена потенциальная проблема с несовместимыми изменениями API библиотек на динамических языках? А с несовместимым изменением поведения кода при сохр https://www.opennet.me/openforum/vsluhforumID3/77309.html#54 Tue, 31 May 2011 21:48:01 GMT &gt; Миш, ну откуда DLL Hell-то, а?<br>&gt; В Юниксе библиотеки версионируются, здесь вам не Windows. К тому же, есть <br>&gt; -Wl,-rpath, да и LD_LIBRARY_PATH, как я отмечал.<br><br>Из возможности положить в "одинаковые" libA.so.X немного разным образом собранный код, например. При этом без дополнительного анализа ABI формализация зависимостей вдруг может оказаться на практике неполной: soname не определяет ключи компиляции как минимум, да и вообще ABI (некоторые апстримы не заморачиваются поднимать soname, чуточку поломав ABI).<br><br>Алексей Турбин в альте эту проблему анализировал и решил, поскольку централизованных репозиториев она (ессно) тоже касается, но там по крайней мере возможно централизованно же и ловить такие крайние случаи.<br> https://www.opennet.me/openforum/vsluhforumID3/77309.html#53 Sun, 29 May 2011 20:10:35 GMT &gt;Гобо - не юникс вэй.<br><br>Это еще почему?<br> https://www.opennet.me/openforum/vsluhforumID3/77309.html#52 Sat, 28 May 2011 10:45:04 GMT угу, только не такую кривую...<br>Лозунг дня: "Даешь все в /Program files"<br> https://www.opennet.me/openforum/vsluhforumID3/77309.html#51 Thu, 26 May 2011 18:33:26 GMT Миш, ну откуда DLL Hell-то, а?<br><br>В Юниксе библиотеки версионируются, здесь вам не Windows. К тому же, есть -Wl,-rpath, да и LD_LIBRARY_PATH, как я отмечал.<br> https://www.opennet.me/openforum/vsluhforumID3/77309.html#50 Thu, 26 May 2011 08:20:46 GMT &gt; Даже при неизменности стабильной ветки системный пакет может оказаться невостребованным <br>&gt; с точки зрения администратора/aptitude.<br><br>Это за пределами ответственности ZI. Если системное окружение не согласуется с потребностями пользователей, можно к нему не привязываться изначально, либо привязываться ограниченно - к glibc и другим пакетам, всегда установленным в системе. В теории проблема есть, на практике не сталкивался.<br><br>&gt; Случай с flash -- пожалуй, да, а вот ряд вариаций на тему <br>&gt; съезда ABI конкретно в альте уже ловится (set-versions).<br><br>Не знаю, есть ли подобное в ZI, не сталкивался опят же. Но там возможен откат на предыдущую версию, и в принципе возможно реализовать аналог set-versions.<br><br>&gt; Где-то firefox, где-то iceweasel, где-то mozilla-firefox... тут относительно просто только <br>&gt; с библиотеками, если ориентироваться исключительно на soname.<br><br>Всё просто: имя пакета можно указать явно для каждого дистрибутива или группы дистрибутивов, а также ограничить допустимые версии зависимостей. Но за https://www.opennet.me/openforum/vsluhforumID3/77309.html#49 Thu, 26 May 2011 07:54:27 GMT Дистр интересный, но не совсем живой :/ <br>И это не оказывает что хоть 1 разработчик (а не мейнтейнер гоболинукса) выложил свою прогу в формате зеро инсталл.<br> https://www.opennet.me/openforum/vsluhforumID3/77309.html#48 Thu, 26 May 2011 07:38:25 GMT &gt; Получается несколько более гибкий вариант (semi)static, и какую проблему это решает?<br><br>Получается более гибкий вариант традиционного пакетирования. В зависимости от ситуации, решается немало проблем.<br><br>1. Для установки пакетов не требуются привилегии суперпользователя (ни в каком виде).<br>2. К вопросу об эффективности. В ZI реализовано безопасное совместное использование файлов (включая либы и экзешники) разными пользователями. Это в отличие от пользовательских RPM-окружений, которые вы предложили в своём письме в качестве аналога.<br>3. Возможность установки пакетов разных версий (и в смысле номеров, и в смысле опций сборки) без дополнительных усилий по обеспечению их бесконфликтного сосуществования.<br>4 Возможность мгновенно и без нарушения консистентности окружения (зависимостей, общих файлов) откатываться на предыдущие версии.<br>5. Каждый пользователь сам выбирает, что и из каких источников ставить и обновлять.<br>5. Каждый пользователь может создавать пакеты для себя и других, а также совмещать их с пакетами https://www.opennet.me/openforum/vsluhforumID3/77309.html#47 Thu, 26 May 2011 05:34:17 GMT &gt; Не-не, что _обычно_ делают (и как именно) -- я знаю. Только <br>&gt; это подразумевает наличие одного общесистемного пакета-провайдера каждого такого сонейма. <br>&gt; А вот как с их вариантом bundle'инга это разумным образом <br>&gt; сопрячь, сходу не соображу (если рассматривать вкупе со следующим вопросом).<br><br>*нудным менторским голосом цитирует FAQ с сайта ZI*<br><br>Isn't it wasteful for every program to bundle all its dependencies?<br><br>Yes, but Zero Install doesn't do that. Everything is dynamically linked, just as in a traditional Linux system: you can publish a program on your web-site that links against a library on another web-site. When updates are available for a library, they are used by all programs using that library (except for programs which are incompatible with the new library version, which will continue using the older version, without preventing other programs from upgrading).<br><br>&gt;&gt; Обновляем libpng <br>&gt; Где именно?<br><br>В пакете, который предоставляет эту библиотеку.<br>