Почему в программном обеспечении Ubuntu так много файлов зависимостей (.deb), а в Windows и Mac - нет?

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

Когда вы устанавливаете программу, ее зависимости должны быть установлены одновременно. Обычно большинство необходимых зависимостей уже установлено, но может потребоваться и несколько дополнительных функций. Поэтому, когда вы устанавливаете пакет, не удивляйтесь, если будут установлены и другие пакеты - это просто зависимости, которые необходимы для правильной работы выбранного вами пакета.

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

^{Источник: Справка Ubuntu}

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

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

• Допустим, библиотека JPEG libjpeg8 содержит серьезную ошибку, и предположим, что у вас запущено 12 приложений, которые используют это для отображения изображений JPEG. Затем, если выдается исправление, не нужно исправлять ни одно приложение, а только пакет libjpeg8 (который действительно мал). Это экономит много работы как для разработчиков приложений, так и для отдельных конечных пользователей, устанавливающих обновления. Это повышает безопасность.

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

• Также возможно иметь дополнительные функции. Предположим, вы разрабатываете приложение и хотите включить функцию, но она нужна не всем. Затем вы можете просто добавить «рекомендованную» зависимость, чтобы эта функция работала только в том случае, если она установлена, но пользователям, не заинтересованным в этом, не нужно ее устанавливать. Это особенно полезно, если зависимость действительно большая. Так работает большинство метапакетов, например texlive-full - это полная установка TexLive (1,5 ГБ!) Со всеми рекомендуемыми шрифтами, но вы также можете установить texlive-base, чтобы иметь только базовую функциональность (~ 100 МБ). Это уменьшает дисковое пространство (если выбрано).

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

• Другая причина - след памяти. Если приложение уже загружено в память библиотекой, и другое приложение также хочет использовать ее, ее не нужно снова загружать в память. Итак, ваш просмотрщик изображений и ваш веб-браузер просто поделятся библиотекой libjpeg8, уже загруженной. Это уменьшает время загрузки и память .

Приложения Windows обычно очень переносимы. Большинство библиотек статически встроены в установщики, и поэтому типичная установка Windows так велика. Также патчи должны быть развернуты для приложения индивидуально, так что это одна из причин, почему вы видите так много отдельных обновлений, например «Adobe Updater», «HP Updater», «Java Updater» и т. Д. Очевидно, что это гораздо менее эффективно.