Ад зависимостей

редактировать

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

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

Содержание

  • 1 Проблемы
  • 2 Решения
  • 3 Платформа
  • 4 См. Также
  • 5 Ссылки
  • 6 Внешние ссылки

Проблемы

Ад зависимостей принимает несколько форм:

Многие зависимости
Приложение зависит от множества библиотек, требует длительных загрузок, большого объема дискового пространства и очень переносимо (все библиотеки уже портированы, что позволяет само приложение легко портируется). Также может быть сложно найти все зависимости, которые можно исправить с помощью репозитория (см. Ниже). Отчасти это неизбежно; приложение, построенное на данной вычислительной платформе (например, Java ), требует, чтобы эта платформа была установлена, но другие приложения этого не требуют. Это особая проблема, если приложение использует небольшую часть большой библиотеки (которая может быть решена с помощью рефакторинга кода ) или простое приложение использует множество библиотек.
Длинные цепочки зависимостей
Если appзависит от liba, который зависит от libb,..., который зависит от libz. Это отличается от "многих зависимостей", если зависимости должны быть разрешены вручную (например, при попытке установить appпользователю предлагается сначала установить liba. При попытке установить liba, затем пользователю предлагается установить libbи т. Д.). Однако иногда во время этой длинной цепочки зависимостей возникают конфликты, когда требуются две разные версии одного и того же пакета (см. конфликтующие зависимости ниже). Эти длинные цепочки зависимостей можно решить с помощью диспетчера пакетов, который автоматически разрешает все зависимости. Помимо хлопот (для разрешения всех зависимостей вручную), ручное разрешение может маскировать циклы или конфликты зависимостей.
Конфликтующие зависимости
Если app1зависит от libfoo 1.2и app2зависит от libfoo 1.3, и разные версии libfooне могут быть установлены одновременно, тогда app1и app2нельзя использовать одновременно (или установить, если установщик проверяет зависимости). Когда это возможно, это решается путем одновременной установки различных зависимостей. В качестве альтернативы, существующая зависимость вместе со всем программным обеспечением, которое от нее зависит, должны быть удалены, чтобы установить новую зависимость. Проблема в системах Linux с установкой пакетов от другого распространителя (что не рекомендуется или даже не должно работать) заключается в том, что в результате длинная цепочка зависимостей может привести к конфликтующей версии стандартной библиотеки C (например, Библиотека GNU C ), от которой зависят тысячи пакетов. Если это произойдет, пользователю будет предложено удалить все эти пакеты.
Циклические зависимости
Если приложение Aзависит от конкретной версии и не может работать без нее. приложение B, но приложение B, в свою очередь, зависит от конкретной версии приложения Aи не может работать без нее, тогда обновление любого приложения приведет к поломке другого. Эта схема может быть более глубокой в ​​разветвлении. Его влияние может быть довольно сильным, если оно влияет на основные системы или само обновление программного обеспечения: диспетчер пакетов (A), для работы которого требуется конкретная библиотека времени выполнения (B), может блокировать себя (A) в середине процесса, когда обновление этой библиотеки (B) до следующей версии. Из-за неправильной версии библиотеки (B) диспетчер пакетов (A) теперь не работает, поэтому откат или более ранняя версия библиотеки (B) невозможны. Обычное решение - загрузить и развернуть оба приложения, иногда во временной среде.
Зависимости диспетчера пакетов
Ад зависимостей может возникнуть в результате установки подготовленного пакета через диспетчер пакетов (например, APT ), но это маловероятно, поскольку основные менеджеры пакетов уже созрели, а официальные репозитории поддерживаются в хорошем состоянии. Так обстоит дело с текущими выпусками Debian и основными производными, такими как Ubuntu. Однако ад зависимостей может возникнуть в результате установки пакета напрямую через установщик пакета (например, RPM или dpkg ).
Diamond dependency
Когда библиотека A зависит от библиотек B и C, и B, и C зависят от библиотеки D, но для B требуется версия D.1, а для C требуется версия D.2. Сборка завершается неудачно, поскольку в конечном исполняемом файле может существовать только одна версия D
Менеджеры пакетов, такие как yum, подвержены конфликтам между пакетами своих репозиториев, вызывая ад зависимостей в таких дистрибутивах Linux, как CentOS и Red Hat Enterprise Linux.

Solutions

Нумерация версий
Очень распространенное решение этой проблемы - иметь стандартизованную систему нумерации, в которой программное обеспечение использует определенный номер для каждой версии (также известный как основная версия ), а также подномер для каждой версии (также известный как дополнительная версия ), например: 10 .1 или 5. 7 . Основная версия изменяется только тогда, когда программы, которые использовали эту версию, больше не будут совместимы. м Версия inor может измениться даже после простой ревизии, которая не мешает другому программному обеспечению работать с ней. В подобных случаях программные пакеты могут просто запросить компонент, имеющий конкретную основную версию и любую вспомогательную версию (больше или равную определенной вспомогательной версии). Таким образом, они будут продолжать работать, а зависимости будут успешно разрешены, даже если младшая версия изменится. Семантическое управление версиями (также известное как «SemVer») - это один из примеров попытки создать техническую спецификацию, в которой используются специально отформатированные числа для создания схемы управления версиями программного обеспечения.
Частное для каждой версии приложения
Защита файлов Windows, представленная в Windows 2000 не позволяла приложениям перезаписывать системные библиотеки DLL. Вместо этого разработчикам предлагалось использовать «частные библиотеки DLL», копии библиотек для каждого приложения в каталоге приложения. При этом используется характеристика пути поиска Windows, согласно которой локальный путь всегда имеет приоритет перед системным каталогом с общесистемными библиотеками. Это позволяет легко и эффективно затенять версии библиотеки конкретными приложениями, тем самым предотвращая ад зависимостей.
Параллельная установка нескольких версий
Решение для нумерации версий можно улучшить, повысив нумерацию версий к функции, поддерживаемой операционной системой. Это позволяет приложению запрашивать модуль / библиотеку по уникальному имени и ограничениям номера версии, эффективно передавая ответственность за брокерскую передачу версий библиотеки / модуля от приложений к операционной системе. Затем общий модуль можно разместить в центральном репозитории без риска поломки приложений, которые зависят от предыдущих или более поздних версий модуля. Каждая версия получает свою собственную запись рядом с другими версиями того же модуля.
Это решение используется в операционных системах Microsoft Windows, начиная с Windows Vista, где Global Assembly Cache - это реализация такого центрального реестра со связанными службами, интегрированная с системой установки / менеджером пакетов. Gentoo Linux решает эту проблему с помощью концепции, называемой слотами, которая позволяет устанавливать несколько версий разделяемых библиотек.
Интеллектуальное управление пакетами
Некоторые менеджеры пакетов могут выполнять интеллектуальные обновления, при которых взаимозависимые программные компоненты обновляются одновременно, тем самым решая проблему несовместимости основных номеров.
Во многих текущих дистрибутивах Linux также реализовано репозиторий системы управления пакетами, чтобы попытаться решить проблему зависимости. Эти системы являются слоем поверх RPM, dpkg или других систем упаковки, которые предназначены для автоматического разрешения зависимостей путем поиска в предопределенных репозиториях программного обеспечения. Примеры этих систем: Apt, Yum, Urpmi, ZYpp, Portage, Pacman и другие. Обычно репозиториями программного обеспечения являются сайты или веб-сайты FTP, каталоги на локальном компьютере или совместно используемые в сети или, что гораздо реже, каталоги на съемных носителях, таких как как CD или DVD. Это устраняет ад зависимостей для программного обеспечения, упакованного в эти репозитории, которые обычно поддерживаются поставщиком дистрибутива Linux и зеркалируются по всему миру. Хотя эти репозитории часто огромны, невозможно разместить в них все программы, поэтому ад зависимостей все равно может возникнуть. Во всех случаях специалисты по сопровождению репозитория по-прежнему сталкиваются с адом зависимости.
PC-BSD, до версии 8.2 включительно, предшественник TrueOS (операционная система на основе FreeBSD ) избегает ада зависимостей, помещая пакеты и зависимости в автономные каталоги в / Programs, что позволяет избежать поломки при обновлении или изменении системных библиотек. Он использует свой собственный PBI (установщик кнопок) для управления пакетами.
Параметры установщика
Поскольку разные части программного обеспечения имеют разные зависимости, можно попасть в порочный круг зависимости требований, или постоянно расширяющееся дерево требований, поскольку каждый новый пакет требует установки еще нескольких. Такие системы, как Debian Advanced Packaging Tool, могут решить эту проблему, предлагая пользователю ряд решений и позволяя пользователю принимать или отклонять решения по своему усмотрению.
Простая адаптируемость в программировании
Если прикладное программное обеспечение спроектировано таким образом, что его программисты могут легко адаптировать уровень интерфейса, который имеет дело с ОС, оконным менеджером или средой рабочего стола, к новым или меняющимся стандартам, тогда программистам нужно будет только отслеживать уведомления от создатели среды или разработчики библиотек компонентов и быстро настраивают свое программное обеспечение, добавляя обновления для своих пользователей, с минимальными усилиями и отсутствием дорогостоящей и трудоемкой модернизации. Этот метод побудит программистов оказывать давление на тех, от кого они зависят, чтобы они поддерживали разумный процесс уведомления, не обременительный для всех участников.
Строгие требования совместимости при разработке и сопровождении кода
Если приложения и библиотеки разрабатываются и поддерживается с учетом гарантированной обратной совместимости, любое приложение или библиотека могут быть заменены на более новую версию в любое время без каких-либо поломок. Хотя это не уменьшает множества зависимостей, но значительно упрощает работу менеджеров пакетов или установщиков.
Программные устройства
Другой подход к устранению проблем с зависимостями - развертывание приложений в виде программного устройства. Программный комплекс инкапсулирует зависимости в предварительно интегрированный автономный модуль, так что пользователям больше не нужно беспокоиться о разрешении программных зависимостей. Вместо этого бремя перекладывается на разработчиков программного обеспечения.
Портативные приложения
Приложение (или версия существующего стандартного приложения), которое полностью автономно и не требует, чтобы ничего уже было установлено. Он закодирован так, чтобы в него были включены все необходимые компоненты, или он предназначен для хранения всех необходимых файлов в своем собственном каталоге и не создает проблем с зависимостями. Часто они могут работать независимо от системы, к которой они подключены. Приложения в RISC OS и ROX Desktop для Linux используют каталоги приложений, которые работают примерно одинаково: программы и их зависимости автономны в своих собственные каталоги (папки).
Этот метод распространения также оказался полезным при переносе приложений, разработанных для Unix-подобных платформ, в Windows, наиболее заметным недостатком является несколько установок одних и тех же разделяемых библиотек. Например, установщики Windows для GIMP и XChat включают идентичные копии набора инструментов GTK +, которые эти программы используют для визуализации виджетов. С другой стороны, если каждому приложению требуются разные версии GTK +, то это правильное поведение и позволяет успешно избежать ада зависимостей.

Платформенный

На определенных вычислительных платформах, «ад зависимостей» часто имеет определенное локальное имя, обычно это имя компонентов.

  • DLL Hell - форма ада зависимостей, возникающая в Microsoft Windows.
  • Конфликт расширений - форма ада зависимостей, возникающая в классической Mac OS.
  • JAR hell - форма ада зависимостей, возникающая в Java Runtime Environment до того, как инструменты сборки, такие как Apache Maven, решили эту проблему еще в 2004 году.
  • RPM hell - форма об аде зависимости, происходящем в дистрибутиве Red Hat Linux и других дистрибутивах, которые используют RPM в качестве диспетчера пакетов.

См. также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-05-17 13:56:59
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте