Как поспешные пакеты обрабатывают совместно использованные зависимости?
Снимок упаковочный формат наконец освобождает нас от ада зависимости, позволяя каждому пакету иметь его собственную копию зависимостей. Я интересуюсь техническими деталями в том, как это делает это. Как делает это обрабатывает:
- снимки в зависимости от версии библиотеки уже установлены через deb пакеты для текущего выпуска? Это игнорирует установленную библиотеку?
- различные снимки, указывающие ту же версию той же библиотеки? Это делает дедупликацию так или иначе?
- обновления оперативных библиотек, которыми, вероятно, будет пользоваться много снимков? OpenSSL приходит на ум как огромная болевая точка.
xdg-приложение имеет что-то позвонившее "время выполнения":
Фундаментальное понятие в xdg-приложении является разделением времени выполнения/приложения. Каждое приложение зависит от времени выполнения, которое предоставляет оперативные библиотеки, на которые полагается приложение. Время выполнения обычно совместно используется многими приложениями, но у пользователя может быть несколько времени выполнения, установленного одновременно.
Кажется, что в случае OpenSSL, это была бы часть времени выполнения в xdg-приложениях, таким образом, обновление OpenSSL должно прозрачно влиять на все xdg-приложения с помощью того же времени выполнения.
3 ответа
Первые две ситуации обрабатываются умным способом.
Одна из интересных функций говорила о, поддержка дедупликации содержания в Поспешных пакетах. Снимки были бы автоматически дедуплицированы общих файлов, совместно использованных между снимками, основанными на их хешах файла. Была бы дедупликация на слое файловой системы, дедупликация на поспешных загрузках (с поддержкой сервера) и возможно дедупликация отображенных библиотек от компоновщика. Дедупликация является большим объектом работы и вероятно будет требовать времени к реализации полностью, но это - интересная цель, тем не менее.
Источник: http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snappy-Deduplication
Что касается третьей ситуации, у них есть что-то подобное времени выполнения, которое Вы упомянули:
Существует три слоя, которые составляют мгновенную машину: системный слой, обеспеченный Каноническим, слоем платформ, которые расширяют основную систему, созданную поставщиками в сотрудничестве с Каноническим, и ряд мгновенных приложений, предоставленных непосредственно поставщиками. Обновление любой части просто означает использовать новую версию изображения только для чтения. Возвращение к предыдущей версии так же легко.
Источник: http://www.ubuntu.com/cloud/snappy
Нет никакой хорошей документации еще, описывающей платформы, прежде всего, потому что они, кажется, все еще разрабатывают границы того, какова платформа. Вот выборка из их списка рассылки, который мог бы помочь разъяснить вещи.
Я экспериментирую с Платформами для важного расширения Мгновенной основной системы программным обеспечением и сервисами, которых много снимков требует, но не должно быть включено ни в кого и каждый снимок, должный обновить проблемы и размер. Лучший пример, который я имею для этого, openssl двоичный файл. Для многих снимков нужно это, чтобы генерировать и проверить ключи и сертификаты.
Другой проблемой, которую я связал для решения с платформой, является доступ к ресурсам в масштабе всей системы, пятнышко особенно порты. Например, платформа веб-сервера обеспечила бы пути к другим снимкам для введения их API веб-сервиса и конечных точек через обратный прокси в платформу, выполняющую веб-сервер.
Мне сказали на IRC, что я - вид злоупотребления понятием платформы, но все еще эти две проблемы часто подходят на моем столе.
Источник: https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000442.html
Я не думаю, что снимки проверяют, какие зависимости уже установлены. Это просто включает все свои зависимости и время выполнения (который является частично, почему снимок LibreOffice составляет 287 МБ, и плоский корпус составляет приблизительно 200 МБ).
Снимки включают в значительной степени все, что программное обеспечение должно выполнить. Я не думаю, что что-либо совместно используется снимками.
Когда снимок обновит однако, он только загрузит зависимости, которые являются новыми, а не весь снимок.
Дополнительное разъяснение в порядке о способе, которым поспешные упаковочные дескрипторы совместно использовали зависимости.
Снимки включают в значительной степени все, что программное обеспечение должно выполнить. Я не думаю, что что-либо совместно используется снимками.
Этот оператор в одном из ответов частично верен, однако все установленные поспешные пакеты за исключением базового снимка зависят от двух пакетов, один из которых является базовым снимком.
snapd - который установлен по умолчанию в 16,04 и вперед и может также быть установлен в 14,04.
ядро - (базовый снимок), который автоматически загружен и установлен, когда первый установленный поспешный пакет установлен
Все поспешные пакеты за исключением самого ядра зависят от базового снимка. Если будет что-то не так с базовым снимком, то некоторые или все другие снимки не будут работать. Проблема с базовым снимком может быть решена следующими двумя способами.
Обновите базовый снимок. Даже если это не будет работать, то результаты выполнения следующей команды предоставят дополнительную информацию, которая поможет решить проблему.
sudo snap refresh coreУдалите базовый снимок и все поспешные пакеты и затем переустановите их.
sudo snap remove core snap-package1 snap-package2 sudo snap install core snap-package1 snap-package2