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

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

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

Проблемы [ править ]

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

Множество зависимостей: Приложение зависит от множества библиотек , требует длительных загрузок, большого объема дискового пространства и очень портативно (все библиотеки уже портированы, что позволяет легко переносить само приложение). Также может быть сложно найти все зависимости, которые можно исправить, имея репозиторий (см. ниже). Отчасти это неизбежно; приложение, созданное на определенной вычислительной платформе (например, Java ), требует установки этой платформы, но дальнейшие приложения не требуют ее. Это особая проблема, если приложение использует небольшую часть большой библиотеки (эту проблему можно решить рефакторингом кода ) или простое приложение использует множество библиотек. ^[2]
Длинные цепочки зависимостей: Если app зависит от liba, что зависит от libb, ..., что зависит от libz. Это отличается от «множества зависимостей», если зависимости необходимо разрешать вручную, например, при попытке установки. app, пользователю будет предложено установить liba сначала и при попытке установки liba, пользователю будет предложено установить libb, и так далее. Однако иногда в этой длинной цепочке зависимостей возникают конфликты, когда требуются две разные версии одного и того же пакета. ^[3](см. конфликтующие зависимости ниже). Эти длинные цепочки зависимостей можно решить с помощью менеджера пакетов, который автоматически разрешает все зависимости. Помимо хлопот (для разрешения всех зависимостей вручную), ручное разрешение может маскировать циклы зависимостей или конфликты.
Конфликтующие зависимости: Решение зависимостей для одного программного обеспечения может нарушить совместимость другого, аналогично тому, как это произошло с «Ударь крота» . Если app1 зависит от libfoo 1.2, и app2 зависит от libfoo 1.3и разные версии libfoo невозможно установить одновременно, то app1 и app2невозможно одновременно использовать (или устанавливать, если установщик проверяет зависимости). Когда это возможно, эту проблему можно решить, разрешив одновременную установку различных зависимостей. Альтернативно, чтобы установить новую зависимость, необходимо удалить существующую зависимость вместе со всем программным обеспечением, которое от нее зависит. Проблема в системах Linux с установкой пакетов от другого дистрибутива (что не рекомендуется). ^{[ нужна цитата ]}заключается в том, что результирующая длинная цепочка зависимостей может привести к конфликтующей версии стандартной библиотеки C (например, GNU C Library ), от которой зависят тысячи пакетов. Если это произойдет, пользователю будет предложено удалить все эти пакеты.
Круговые зависимости: Если application A зависит от конкретной версии и не может работать без нее application B, но application B, в свою очередь, зависит от конкретной версии и не может работать без нее. application A, то обновление любого приложения приведет к поломке другого. Эта схема может быть более глубокой по ветвлению. Его влияние может быть весьма тяжелым, если оно затрагивает основные системы или само обновление программного обеспечения: менеджер пакетов (A), для работы которого требуется определенная библиотека времени выполнения (B), может сломаться (A) в середине процесса при обновлении. эту библиотеку (B) до следующей версии. Из-за неправильной версии библиотеки (B) менеджер пакетов (A) теперь не работает, поэтому откат или понижение версии библиотеки (B) невозможны. Обычное решение — загрузить и развернуть оба приложения, иногда во временной среде.
Зависимости менеджера пакетов: Возможно ^[4]Ад зависимостей может возникнуть в результате установки подготовленного пакета через менеджер пакетов (например, APT ), но это маловероятно, поскольку основные менеджеры пакетов уже созрели, а официальные репозитории поддерживаются в хорошем состоянии. Так обстоит дело с текущими выпусками Debian и его основными производными, такими как Ubuntu . Однако ад зависимостей может возникнуть в результате установки пакета непосредственно через установщик пакетов (например, RPM или 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]; PC-BSD, до версии 8.2 включительно, предшественник TrueOS (операционная система на основе FreeBSD ), помещает пакеты и зависимости в автономные каталоги в /Programs , что позволяет избежать поломок в случае обновления или изменения системных библиотек. Для управления пакетами он использует собственный «PBI» (кнопочный установщик). ^[8]
Параллельная установка нескольких версий: Решение по нумерации версий можно улучшить, повысив нумерацию версий до функции, поддерживаемой операционной системой. Это позволяет приложению запрашивать модуль/библиотеку по уникальному имени и ограничениям по номеру версии, эффективно передавая ответственность за посредничество версий библиотеки/модуля от приложений к операционной системе. Общий модуль затем можно поместить в центральный репозиторий без риска нарушения работы приложений, которые зависят от предыдущих или более поздних версий модуля. Каждая версия имеет свою собственную запись рядом с другими версиями того же модуля.; Это решение используется в операционных системах Microsoft Windows, начиная с Windows Vista, где глобальный кэш сборок представляет собой реализацию такого центрального реестра со связанными службами и интегрирован с системой установки/менеджером пакетов. Gentoo Linux решает эту проблему с помощью концепции слотирования, которая позволяет устанавливать несколько версий общих библиотек. ^[9]
Умное управление пакетами: Некоторые менеджеры пакетов могут выполнять интеллектуальные обновления, при которых взаимозависимые компоненты программного обеспечения обновляются одновременно, тем самым решая также основную проблему несовместимости номеров.; Многие текущие дистрибутивы Linux также реализовали системы управления пакетами на основе репозитория , чтобы попытаться решить проблему зависимостей. Эти системы представляют собой слой поверх RPM , dpkg или других систем упаковки, которые предназначены для автоматического разрешения зависимостей путем поиска в предопределенных репозиториях программного обеспечения . Примеры таких систем включают Apt , Yum , Urpmi , ZYpp , Portage , Pacman и другие. Обычно репозиториями программного обеспечения являются FTP -сайты или веб-сайты, каталоги на локальном компьютере или общие в сети или, что гораздо реже, каталоги на съемных носителях, таких как компакт-диски или DVD-диски. Это устраняет ад зависимостей для программного обеспечения, упакованного в эти репозитории, которые обычно поддерживаются поставщиком дистрибутива Linux и зеркалируются по всему миру. Хотя эти репозитории часто огромны, в них невозможно разместить все части программного обеспечения, поэтому ад зависимости все равно может возникнуть. Во всех случаях сопровождающие репозитория по-прежнему сталкиваются с адом зависимостей. ^[4]
Опции установщика: Поскольку разные части программного обеспечения имеют разные зависимости, можно попасть в порочный круг к зависимостям требований или в постоянно расширяющееся дерево требований, поскольку каждый новый пакет требует установки еще нескольких. Debian, Такие системы, как Advanced Packaging Tool могут решить эту проблему, предоставляя пользователю ряд решений и позволяя пользователю принять или отклонить эти решения по своему желанию.
Легкая адаптируемость в программировании: Если прикладное программное обеспечение спроектировано таким образом, что его программисты могут легко адаптировать уровень интерфейса, связанный с ОС, оконным менеджером или средой рабочего стола, к новым или меняющимся стандартам, то программистам придется только отслеживать уведомления от создателей среды. или проектировщикам библиотек компонентов и быстро корректировать свое программное обеспечение с помощью обновлений для своих пользователей, и все это с минимальными усилиями и без дорогостоящего и трудоемкого изменения дизайна. Этот метод побудит программистов оказывать давление на тех, от кого они зависят, чтобы они поддерживали разумный процесс уведомления, который не был бы обременительным для всех участников.
Строгое требование совместимости при разработке и сопровождении кода.: Если приложения и библиотеки разрабатываются и поддерживаются с учетом гарантированной совместимости с предыдущими версиями, любое приложение или библиотеку можно заменить более новой версией в любое время, ничего не нарушая. Хотя это не уменьшает множество зависимостей, это значительно упрощает работу менеджеров пакетов или установщиков.
Программные устройства: Другой подход, позволяющий избежать проблем с зависимостями, — развертывание приложений в виде программного устройства . Программное устройство инкапсулирует зависимости в предварительно интегрированном автономном блоке, так что пользователям больше не придется беспокоиться о разрешении программных зависимостей. Вместо этого бремя перекладывается на разработчиков программного обеспечения. Контейнеры и их образы (например, предоставляемые Docker и Docker Hub) можно рассматривать как реализацию программных устройств.
Портативные приложения: Приложение (или версия существующего обычного приложения), которое является полностью автономным и не требует предварительной установки. Он запрограммирован так, чтобы включать все необходимые компоненты, или предназначен для хранения всех необходимых файлов в своем собственном каталоге и не создает проблем с зависимостями. Зачастую они могут работать независимо от системы, к которой они подключены. Приложения в ОС RISC и ROX Desktop для Linux используют каталоги приложений , которые работают примерно одинаково: программы и их зависимости находятся в своих собственных каталогах (папках). ^[10]; Этот метод распространения также оказался полезным при портировании приложений, разработанных для Unix-подобных платформ, на Windows, причем наиболее заметным недостатком является множественная установка одних и тех же общих библиотек . Например, установщики Windows для gedit , GIMP и HexChat включают идентичные копии набора инструментов GTK , который эти программы используют для визуализации виджетов. С другой стороны, если каждому приложению требуются разные версии GTK, то это правильное поведение, позволяющее успешно избежать ада зависимостей.

Зависит от платформы [ править ]

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

DLL Hell — форма ада зависимостей, возникающая в 16-разрядной версии Microsoft Windows .
Конфликт расширений — форма ада зависимостей, происходящая в классической Mac OS .
Ад JAR — форма ада зависимостей, возникшая в среде выполнения Java до того, как инструменты сборки, такие как Apache Maven, решили эту проблему в 2004 году. ^{[ нужна цитата ]}
Ад RPM — форма ада зависимостей, возникающая в Red Hat дистрибутиве Linux и других дистрибутивах, использующих RPM в качестве менеджера пакетов. ^[11]

См. также [ править ]

Уловка-22 — литературное изображение ситуаций, в которых что-то зависит от собственного отрицания.
Управление конфигурациями – методы и инструменты управления версиями программного обеспечения.
Связь - формы зависимости между программными артефактами.
Динамическое устранение мертвого кода
Менеджер пакетов
ПБИ
Программное обеспечение
Статическая библиотека
Атака на цепочку поставок
Менеджер пакетов Nix
Левая панель

Ссылки [ править ]

^ Майкл Джанг (2006). Неудобства Linux для гиков . О'Рейли Медиа. п. 325 . ISBN 9780596552244 . Проверено 16 февраля 2012 г.
^ Дональд, Джеймс (25 января 2003 г.). «Улучшенная переносимость общих библиотек» (PDF) . Университет Принстон. Архивировано из оригинала (PDF) 26 сентября 2007 г. Проверено 9 апреля 2010 г.
^ Стивенс, Эл (1 мая 2001 г.). «Хорошая работа, когда вы можете ее найти; Карусель зависимостей» . Джей-ДДДж . 26 (5). www.drdobbs.com/блог: 121–124. ISSN 1044-789X . Архивировано из оригинала 11 августа 2011 г. Проверено 10 апреля 2010 г.
^ Перейти обратно: ^а ^б Петр Принс; Джива Суреш и Элко Долстра (22 декабря 2008 г.). «Nix исправляет ад зависимостей во всех дистрибутивах Linux» . Linux.com. Архивировано из оригинала 8 июля 2015 г. Проверено 22 мая 2013 г. Все популярные менеджеры пакетов, включая APT, RPM и коллекцию портов FreeBSD, страдают от проблемы деструктивных обновлений. Когда вы выполняете обновление — будь то одно приложение или вся ваша операционная система — менеджер пакетов перезапишет файлы, которые сейчас находятся в вашей системе, более новыми версиями. Пока пакеты всегда полностью обратно совместимы, это не проблема, но в реальном мире пакеты далеко не полностью обратно совместимы. Предположим, вы обновляете Firefox, и ваш менеджер пакетов решает, что вам также нужна более новая версия GTK. Если новый GTK не совсем обратно совместим, другие приложения в вашей системе могут внезапно выйти из строя. В мире Windows аналогичная проблема известна как ад DLL, но ад зависимостей — это такая же проблема в мире Unix, если не более серьезная, потому что программы Unix, как правило, имеют множество внешних зависимостей.
^ «Ням ад зависимости» . Архивировано из оригинала 19 декабря 2016 г. Проверено 28 декабря 2015 г.
^ «Сайт проекта: semver.org» .
^ Андерсон, Рик (11 января 2000 г.). «Конец ада DLL» . microsoft.com. Архивировано из оригинала 5 июня 2001 г. Проверено 7 июля 2010 г.
^ pbiDIR
^ Размещение на gentoo.org
^ «Каталоги приложений» . Проверено 7 сентября 2013 г.
^ Вайнштейн, Пол (11 сентября 2003 г.). «Раздражает ли Linux?» . linuxdevcenter.com . Проверено 10 апреля 2010 г.

Внешние ссылки [ править ]

[Dependency_Hell-1] Майкл Джанг (2006). Неудобства Linux для гиков . О'Рейли Медиа. п. 325 . ISBN 9780596552244 . Проверено 16 февраля 2012 г.

[jamesdonald-2] Дональд, Джеймс (25 января 2003 г.). «Улучшенная переносимость общих библиотек» (PDF) . Университет Принстон. Архивировано из оригинала (PDF) 26 сентября 2007 г. Проверено 9 апреля 2010 г.

[Dependency-Carousel-3] Стивенс, Эл (1 мая 2001 г.). «Хорошая работа, когда вы можете ее найти; Карусель зависимостей» . Джей-ДДДж . 26 (5). www.drdobbs.com/блог: 121–124. ISSN 1044-789X . Архивировано из оригинала 11 августа 2011 г. Проверено 10 апреля 2010 г.

[linuxdependencyhell-4] Перейти обратно: ^а ^б Петр Принс; Джива Суреш и Элко Долстра (22 декабря 2008 г.). «Nix исправляет ад зависимостей во всех дистрибутивах Linux» . Linux.com. Архивировано из оригинала 8 июля 2015 г. Проверено 22 мая 2013 г. Все популярные менеджеры пакетов, включая APT, RPM и коллекцию портов FreeBSD, страдают от проблемы деструктивных обновлений. Когда вы выполняете обновление — будь то одно приложение или вся ваша операционная система — менеджер пакетов перезапишет файлы, которые сейчас находятся в вашей системе, более новыми версиями. Пока пакеты всегда полностью обратно совместимы, это не проблема, но в реальном мире пакеты далеко не полностью обратно совместимы. Предположим, вы обновляете Firefox, и ваш менеджер пакетов решает, что вам также нужна более новая версия GTK. Если новый GTK не совсем обратно совместим, другие приложения в вашей системе могут внезапно выйти из строя. В мире Windows аналогичная проблема известна как ад DLL, но ад зависимостей — это такая же проблема в мире Unix, если не более серьезная, потому что программы Unix, как правило, имеют множество внешних зависимостей.

[5] «Ням ад зависимости» . Архивировано из оригинала 19 декабря 2016 г. Проверено 28 декабря 2015 г.

[6] «Сайт проекта: semver.org» .

[endofdllhell-7] Андерсон, Рик (11 января 2000 г.). «Конец ада DLL» . microsoft.com. Архивировано из оригинала 5 июня 2001 г. Проверено 7 июля 2010 г.

[8] DIR

[9] Размещение на gentoo.org

[10] «Каталоги приложений» . Проверено 7 сентября 2013 г.

[linuxcompa-11] Вайнштейн, Пол (11 сентября 2003 г.). «Раздражает ли Linux?» . linuxdevcenter.com . Проверено 10 апреля 2010 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]