Дистрибутивы Linux состоят из кубиков-пакетов, связанных между собой определёнными зависимостями и хранящихся в специальных архивах — репозиториях. При обновлении программ разработчикам приходится тестировать кучу сопутствующего софта, чтобы на выходе не получить конфликтов. К такой ситуации все привыкли, и большинство пользователей она устраивает. Однако в действительности она далека от идеала.
Недавно я пытался установить экспериментальную сборку GIMP в Ubuntu 11.10 из репозитория PPA на сервисе Launchpad и не смог этого сделать без риска сломать основную рабочую ОС. Из-за проблем с зависимостями нужно было подключать другие репозитории и обновлять важные системные компоненты, что чревато новыми программными конфликтами. Не знаю как вам, а мне подобная ситуация кажется нарушением если не буквы, то духа пресловутых четырёх свобод. Судите сами: в свободном дистрибутиве я не могу использовать свободную программу по своему усмотрению.
Парадоксально, но проще всего оказалось установить экспериментальный GIMP в Windows: для этого достаточно было запустить скачанный с sourceforge инсталлятор. И никаких тебе проблем с зависимостями. Понятно, что можно держать на машине VirtualBox с тестовыми ОС, но зачем это простым пользователям настольных дистрибутивов? Им ведь требуется немногое — всего лишь возможность поставить любую прикладную программу, не рискуя сломать рабочую систему. А разработчики предлагают варианты для гиков, вроде дистрибутивов с непрерывным циклом обновлений или использования виртуализации. Слава богу, что собирать ПО вручную уже не заставляют. И зачем делать выбор между новизной и стабильностью софта, рискуя работоспособностью системы, когда нужно всего одно нестабильное приложение? В проприетарных ОС проблема стоит не так остро. Получается, что с точки зрения простых пользователей они более «свободны»?
Проблема даже не в том, что Linux собирается из кубиков, как конструктор Lego, а в Windows и Mac OS X есть базовая ОС и сторонние приложения. Это технические нюансы. Во FreeBSD основная ОС тоже не разбита на кучу мелких блоков, а программы ставятся из портов/пакетов. Проблем с зависимостями там не меньше. Дело в количестве кубиков, которые пытаются контролировать разработчики дистрибутива. Когда их счёт идёт на десятки тысяч, начинаются сложности не то что с нововведениями, с простым обновлением некоторых пакетов. Про то, сколько усилий нужно приложить авторам программы или сборщикам пакета (если авторы не хотят сами этим заниматься), чтобы она попала в репозиторий, я уже не говорю. Они вынуждены следить за работоспособностью огромного множества сопутствующих продуктов. Различные сервисы автосборки и сторонние репозитории здорово помогают, но они не решают проблему полностью в ситуации, когда кроме установки самого приложения приходится с риском для «жизни» обновлять связанные с ним компоненты системы. Непрерывный цикл обновлений всего архива пакетов тоже не вариант, поскольку одновременно с возможностью пробовать новое хочется стабильности системы.
Решить проблему можно только в том случае, если принципиально изменить конструкцию дистрибутива. Необходимо уменьшить количество контролируемых его разработчиками кубиков с зависимостями и сформировать из них небольшую базовую систему (при этом совершенно неважно, будет она состоять из отдельных пакетов или нет, это частности) с хорошо стандартизированными API и ABI. Любые дополнительные пакеты (не имеет значения, контролируются они некой компанией вроде Canonical или независимым сообществом) не должны при установке или обновлении требовать обязательного обновления других пакетов. Кроме того, необходимо по возможности сохранять совместимость интерфейсов между версиями базовой системы.
Не хотелось бы приводить пример Mac OS X, где этой проблемы не существует, — едва ли используемые там методы можно адекватно перенести в Linux. Но почему бы не позаимствовать принцип? Тем более что один удачный пример подобного заимствования в мире СПО есть — это PC-BSD. Она основана на базовой ОС FreeBSD, а для установки программ там используются разработанные в рамках проекта средства — фирменный формат пакетов PBI и собственный репозиторий pbidir.com. В пакет PBI включаются все необходимые библиотеки, что убирает трудности с зависимостями и позволяет инсталлировать приложения без риска сломать систему, но приводит к увеличению используемого дискового пространства. В последней версии продукта эта проблема решена: появилась возможность совместного использования файлов и библиотек различными пакетами.
Для перевода дистрибутивов Linux на подобный подход потребуется огромная работа (стратегию придумать проще всего, с тактикой все куда сложнее), но делать её необходимо. Лично мне уже надоела шаткая, построенная из огромного множества цепляющихся друг за друга элементов система. Она напоминает карточный домик: конструкция выглядит красиво, пока нет потребности заменить один из её элементов, не трогая остальные.