Как пакеты привязки обрабатывают общие зависимости?

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

• зависает в зависимости от версии библиотеки, уже установленной с помощью пакетов deb для текущего выпуска? Это игнорирует установленную библиотеку?
• разные снимки, указывающие одну и ту же версию одной и той же библиотеки? Это делает дедупликацию как-то?
• Обновления основных библиотек, которые могут быть использованы множеством снимков? OpenSSL приходит на ум как огромная болевая точка.

В xdg-app есть что-то, что называется «время выполнения» :

Фундаментальная концепция в xdg-app - это разделение среды выполнения / приложения. Каждое приложение зависит от среды выполнения, которая предоставляет основные библиотеки, на которые опирается приложение. Среда выполнения обычно используется многими приложениями, но пользователь может установить несколько сред выполнения одновременно.

Похоже, что в случае OpenSSL это будет частью среды выполнения в приложениях xdg, поэтому обновление OpenSSL должно прозрачно влиять на все приложения xdg, использующие одну и ту же среду выполнения.

Первые две ситуации обрабатываются с умом.

Одна из интересных функций, о которых говорилось, - это поддержка дедупликации контента в пакетах Snap. Снимки будут автоматически дедуплицированы из общих файлов, совместно используемых снимками, на основе их файловых хэшей. На уровне файловой системы будет происходить дедупликация, дедупликация при мгновенной загрузке (с поддержкой сервера) и, возможно, дедупликация отображенных библиотек из компоновщика. Дедупликация - это большой рабочий элемент, и для его полной реализации, вероятно, потребуется некоторое время, но, тем не менее, это интересная цель.

Источник: http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snappy-Deduplication

Что касается третьей ситуации, у них есть нечто похожее на время выполнения, которое вы упомянули:

Есть три уровня, которые составляют мгновенную машину: системный уровень, предоставляемый Canonical, уровень платформ, расширяющих базовую систему, производимую поставщиками в сотрудничестве с Canonical, и набор мгновенных приложений, предоставляемых непосредственно поставщиками. Обновление любой части просто означает использование новой версии изображения только для чтения. Вернуться к предыдущей версии так же просто.

Источник: http://www.ubuntu.com/cloud/snappy

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

Я экспериментирую с Frameworks, чтобы существенно расширить базовую систему Snappy с помощью программного обеспечения и сервисов, которые требуют много моментальных снимков, но не должны включаться ни в один из них в связи с проблемами и размером обновления. Лучший пример для этого - бинарный файл openssl. Многие снимки нужны для генерации и проверки ключей и сертификатов.

Другая проблема, которую я решил решить с помощью инфраструктуры, - это доступ к общесистемным ресурсам, особенно к портам. Например, инфраструктура веб-сервера предоставит другим snapps возможность внедрять свои API-интерфейсы и конечные точки веб-службы через обратный прокси-сервер в среду, в которой работает веб-сервер.

В IRC мне сказали, что я как бы злоупотребляю концепцией фреймворка, но все же эти два вопроса часто возникают у меня на столе.

Источник: https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000442.html

Я не думаю, что оснастки проверяют, какие зависимости уже установлены. Он просто включает в себя все свои зависимости и время выполнения (именно поэтому отчасти оснастка LibreOffice составляет 287 МБ, а flatpak - около 200 МБ).

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

Однако при обновлении оснастки загружаются только новые зависимости, а не вся привязка.

Дополнительные пояснения касаются того, как Snap Snap обрабатывает общие зависимости.

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

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

1. snapd - который устанавливается по умолчанию в 16.04 и далее, а также может быть установлен в 14.04.

2. core    - (оснастка ядра), которая автоматически загружается и устанавливается при установке первого установленного пакета оснастки

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

1. Обновите ядро ​​оснастки. Даже если это не сработает, результаты выполнения следующей команды предоставят дополнительную информацию, которая поможет решить проблему.

   sudo snap refresh core  
   

2. Удалите оснастку ядра и все пакеты оснастки, а затем переустановите их.

   sudo snap remove core snap-package1 snap-package2  
   sudo snap install core snap-package1 snap-package2