WikiDer > Ад зависимости - Википедия

Ад зависимости это разговорный термин для разочарования некоторых пользователей программного обеспечения, которые установили программные пакеты который имеет зависимости по конкретным версии других программных пакетов.^[1]

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

Проблемы

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

Многие зависимости

Приложение зависит от многих библиотеки, требующий длительных загрузок, большого объема дискового пространства и очень переносимый (все библиотеки уже портированы, что позволяет легко переносить само приложение). Также может быть сложно найти все зависимости, которые можно исправить с помощью репозитория (см. Ниже). Отчасти это неизбежно; приложение, построенное на заданном вычислительная платформа (Такие как Ява) требует, чтобы эта платформа была установлена, но другие приложения этого не требуют. Это особая проблема, если приложение использует небольшую часть большой библиотеки (которую можно решить с помощью рефакторинг кода), или простое приложение использует множество библиотек.^[2]

Длинные цепочки зависимостей

Если приложение зависит от либа, что зависит от libb, ..., что зависит от libz. Это отличается от "многих зависимостей", если зависимости необходимо разрешить вручную (например, при попытке установить приложение, пользователю предлагается установить либа первый. При попытке установить либа, пользователю будет предложено установить libb, и так далее.). Однако иногда во время этой длинной цепочки зависимостей возникают конфликты, когда требуются две разные версии одного и того же пакета.^[3] (видеть конфликтующие зависимости ниже). Эти длинные цепочки зависимостей можно решить с помощью диспетчера пакетов, который автоматически разрешает все зависимости. Помимо хлопот (разрешить все зависимости вручную), ручное разрешение может маскировать циклы зависимостей или конфликты.

Конфликтующие зависимости

Если приложение1 зависит от libfoo 1.2, и app2 зависит от libfoo 1.3, и разные версии libfoo нельзя одновременно установить, то приложение1 и app2 нельзя одновременно использовать (или установить, если установщик проверяет зависимости). Когда это возможно, это решается путем одновременной установки различных зависимостей. В качестве альтернативы, существующая зависимость вместе со всем программным обеспечением, которое от нее зависит, должны быть удалены, чтобы установить новую зависимость. Проблема в системах Linux с установкой пакетов от другого дистрибьютора (что не рекомендуется или даже не должно работать) заключается в том, что в результате длинная цепочка зависимостей может привести к конфликтующей версии Стандартная библиотека C (например, Библиотека GNU C), от которого зависят тысячи пакетов. Если это произойдет, пользователю будет предложено удалить все эти пакеты.

Круговые зависимости

Если приложение А зависит от и не может работать без конкретной версии приложение B, но приложение B, в свою очередь, зависит от конкретной версии и не может работать без нее. приложение А, то обновление любого приложения сломает другое. Эта схема может быть более глубокой в ​​разветвлении. Его влияние может быть довольно сильным, если оно затрагивает основные системы или само обновление программного обеспечения: диспетчер пакетов (A), для работы которого требуется определенная библиотека времени выполнения (B), может блокировать себя (A) в середине процесса, когда обновление этой библиотеки (B) до следующей версии. Из-за неправильной версии библиотеки (B) диспетчер пакетов (A) теперь не работает, поэтому откат или более ранняя версия библиотеки (B) невозможны. Обычное решение - загрузить и развернуть оба приложения, иногда во временной среде.

Зависимости диспетчера пакетов

Это возможно^[4] чтобы ад зависимости возник в результате установки подготовленного пакета через диспетчер пакетов (например, APT), но это маловероятно, поскольку основные менеджеры пакетов достигли зрелости, а официальные репозитории поддерживаются в хорошем состоянии. Так обстоит дело с текущими выпусками Debian и основные производные, такие как Ubuntu. Однако ад зависимостей может возникнуть в результате установки пакета напрямую через установщик пакета (например, Об / мин или же dpkg).

Алмазная зависимость

Когда библиотека A зависит от библиотек B и C, и B, и C зависят от библиотеки D, но для B требуется версия D.1, а для C требуется версия D.2. Сборка не выполняется, потому что в конечном исполняемом файле может существовать только одна версия D.

Менеджеры пакетов вроде ням,^[5] склонны к конфликтам между пакетами своих репозиториев, вызывая ад зависимостей в таких дистрибутивах Linux, как CentOS и Red Hat Enterprise Linux.

Решения

Нумерация версий

Очень распространенное решение этой проблемы - иметь стандартизированную систему нумерации, в которой программное обеспечение использует определенный номер для каждой версии (также известный как основная версия), а также подномер для каждой ревизии (также известный как второстепенная версия), например: 10.1 или 5.7. Основная версия изменяется только тогда, когда программы, использовавшие эту версию, больше не будут совместимы. Дополнительная версия может измениться даже после простой ревизии, которая не мешает другим программам работать с ней. В подобных случаях программные пакеты могут просто запросить компонент, имеющий определенную основную версию, и любой дополнительная версия (больше или равна определенной дополнительной версии). Таким образом, они будут продолжать работать, а зависимости будут успешно разрешены, даже если младшая версия изменится. Семантическое управление версиями (также известное как "SemVer" ^[6]) является одним из примеров попытки создать техническую спецификацию, в которой используются специально отформатированные числа для создания схемы управления версиями программного обеспечения.

Частный для каждой версии приложения

Защита файлов Windows введено в Windows 2000 запретил приложениям перезаписывать системные библиотеки DLL. Вместо этого разработчикам предлагалось использовать «частные библиотеки DLL», копии библиотек для каждого приложения в каталоге приложения. При этом используется характеристика пути поиска Windows: локальный путь всегда имеет приоритет перед системным каталогом с общесистемными библиотеками. Это позволяет легко и эффективно дублировать версии библиотеки конкретными приложениями, тем самым предотвращая ад зависимостей.^[7]

Параллельная установка нескольких версий

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

Это решение используется в Майкрософт Виндоус операционных систем, начиная с Windows Vista, где Глобальный кэш сборок представляет собой реализацию такого центрального реестра со связанными службами, интегрированного с системой установки / менеджером пакетов. Gentoo Linux решает эту проблему с помощью концепции, называемой слотами, которая позволяет устанавливать несколько версий разделяемых библиотек.^[8]

Умное управление пакетами

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

Многие текущие Linux дистрибутивы также реализовали хранилищесистемы управления пакетами, чтобы попытаться решить проблему зависимости. Эти системы являются слоем над Об / мин, dpkgили другие системы упаковки, которые предназначены для автоматического разрешения зависимостей путем поиска в предварительно определенных программные репозитории. Примеры этих систем включают Квартира, Ням, Urpmi, ZYpp, Portage, Pacman и другие. Обычно репозитории программного обеспечения FTP сайты или веб-сайты, каталоги на локальном компьютере или через сеть или, что гораздо реже, каталоги на съемных носителях, таких как компакт-диски или DVD. Это устраняет ад зависимостей для программного обеспечения, упакованного в эти репозитории, которые обычно поддерживаются поставщиком дистрибутива Linux и зеркальный Мировой. Хотя эти репозитории часто огромны, невозможно разместить в них все части программного обеспечения, поэтому ад зависимостей все еще может возникнуть. Во всех случаях специалисты по сопровождению репозитория по-прежнему сталкиваются с адом зависимости.^[4]

PC-BSD, до версии 8.2 включительно, предшественник TrueOS (операционная система на базе FreeBSD) избегает ада зависимостей, помещая пакеты и зависимости в автономные каталоги в / Программы, что позволяет избежать поломки при обновлении или изменении системных библиотек. Для управления пакетами он использует собственный PBI (установщик кнопок).^[9]

Параметры установщика

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

Легкая адаптируемость в программировании

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

Строгие требования совместимости при разработке и сопровождении кода

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

Программные устройства

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

Портативные приложения

Приложение (или версия существующего обычного приложения), которое является полностью автономным и не требует предварительной установки. Он закодирован так, чтобы в него были включены все необходимые компоненты, или он предназначен для хранения всех необходимых файлов в своем собственном каталоге и не создает проблем с зависимостями. Часто они могут работать независимо от системы, к которой они подключены. Приложения в ОС RISC и ROX Desktop для использования Linux каталоги приложений, которые работают примерно так же: программы и их зависимости автономны в своих собственных каталогах (папках).^[10]

Этот метод распространения также оказался полезным при переносе приложений, разработанных для Unix-подобных платформ, на Windows, наиболее заметным недостатком является установка нескольких одинаковых общие библиотеки. Например, установщики Windows для gedit, GIMP, и XChat все включают идентичные копии GTK + набор инструментов, который эти программы используют для рендеринга виджетов. С другой стороны, если для каждого приложения требуются разные версии GTK +, то это правильное поведение, позволяющее избежать ада зависимостей.

Для конкретной платформы

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

• DLL ад - форма ада зависимости, происходящая от Майкрософт Виндоус.
• Конфликт расширений - форма ада зависимости, происходящая от классическая Mac OS.
• JAR ад - форма ада зависимости, возникающая в Среда выполнения Java до инструментов сборки, таких как Apache Maven решил эту проблему еще в 2004 году.^{[нужна цитата]}
• RPM hell - разновидность ада зависимости, происходящая в Красная шляпа распределение Linux и другие дистрибутивы, использующие Об / мин как менеджер пакетов.^[11]

Смотрите также

• Управление конфигурацией - методы и инструменты для управления версиями программного обеспечения
• Связь - формы зависимости между программными артефактами
• Динамическое устранение мертвого кода
• Менеджер пакетов
• PBI
• Программное обеспечение
• Менеджер пакетов Nix
• Левая панель

Рекомендации

внешняя ссылка

• Независимость от контекста
• Ходок зависимости
• Неявная зависимость
• MacDependency