Как избавиться от проблем установки ПО в GNU/Linux - Linux - Linux - Каталог статей

В наши дни большинство дистрибутивов (включая великолепный Ubuntu) основаны на менеджерах пакетов. Если вы хотите установить какую-нибудь программу, вы скачиваете её с одного из официальных репозиториев, а менеджер пакетов "разворачивает" её в файловой системе вашего компьютера. Разные части программы разбрасываются по /usr/bin, /usr/lib, /etc и так далее. Обычно это выполняется менеджером пакетов. Например, в Ubuntu вы, скорее всего, будете использовать Synaptic. Менеджер пакетов, как правило, разрешает все "проблемы зависимостей". Ну, зависимости... обычно программе просмотра изображений может для работы требоваться, скажем, libjpeg (библиотека функций для открытия, сохранения и вообще обработки файлов JPEG). Это очень по-юниксовому. Для серверов этот подход работает превосходно, но для клиентских систем на некоторых уровнях не оправдывает надежд. Почему?

У такого подхода есть серьёзные проблемы. Вот достаточно полный, но далеко не исчерпывающий список (который, вероятно, вырастет по мере того как люди будут присылать мне письма):

Пользователи, чтобы установить программу, должны иметь права root; возможность каждому пользователю устанавливать свои программы не предусмотрена.
Для установки нескольких версий одной и той же программы нужна немалая изворотливость. Только представьте себе несчастного дизайнера, которому нужно установить несколько версий Opera и Firefox!
Пользователи "повязаны" с программами, установленными вместе с системой.
Устанавливаемую программу нужно загружать с официальных репозиториев. Ладно, это не обязательно, но от неофициальных репозиториев среднестатистическому пользователю по техническим причинам лучше держаться подальше.
В некоторых случаях (особенно когда пользователь добавляет сторонние репозитории или инсталлирует пакеты непосредственно) механизм проверки зависимостей оказывается неработоспособным, и пользователи остаются один на один с циклическими зависимостями. Это очень неприятно.
Программы привязаны к определённому дистрибутиву, а также - что ещё хуже - к определённой версии этого дистрибутива. Не так просто поставить OpenOffice 3.1 на Ubuntu 8.10. Вы-то можете доказать, что в состоянии установить связку deb-пакетов с веб-сайта OpenOffice.org. Теперь научите этому свою бабушку или вашего пользователя, владеющего компьютером на уровне не выше среднего.
Не очень-то просто дать программу своему другу. С точки зрения конечного пользователя, "дать программу другу" должно выглядеть как перетаскивание некоторой иконки на флешку; но нет - нужные файлы разбросаны по всей системе.

Сейчас на дворе 2009 год, а GNU/Linux всё ещё страдает ото всех этих проблем. Даже Ubuntu, дистрибутив, который я обожаю, и тот страдает от этого - и мы ещё говорим о дистрибутиве, рассчитанном на конечных пользователей!

Как это должно выглядеть

Всё вышесказанное справедливо для OS X от Apple. Там установка ПО выполняется именно таким образом, хотя некоторые программы в последнее время, похоже, начали сопровождаться уродливым процессом установки.

Откуда исходит проблема?

Поймите меня правильно: я считаю, что Ubuntu - фантастическая система, и многое в ней сделано должным образом. Думаю, что источник проблемы лежит, скорее, в области философии.

Этот вопрос является центральным в данной статье и заслуживает того, чтобы быть жирно выделенным:

Каждый дистрибутив GNU/Linux на данный момент (в том числе и Ubuntu) смешивает системные программы и пользовательские, в то время как это две совершенно разные вещи, работать с которыми нужно совершенно по-разному.

На мой взгляд, использование dpkg/apt-get или rpm/yum для системных программ, библиотек и так далее - то, что надо. Успех GNU/Linux в области серверов не случаен: дистрибутив собирается из определённых независимых "кирпичиков", которые составляют величественное здание.

Однако использование этой же философии - а следовательно, и архитектуры - для пользовательских программ влечёт за собой слишком много ограничений. Приведённый мною выше список не является "списком досадных помех". Это - одни из основных причин, по которым GNU/Linux не достиг массового проникновения в сферу настольных систем.

Что меня беспокоит, так это вопрос, почему все прочие проблемы решаются (в том числе и тех.поддержкой поставщиков), а эта остаётся постоянной занозой для пользователей каждой системы GNU/Linux. Очень болезненной занозой.

Существующий материал по данной проблеме

Рассматриваемый вопрос порождает множество споров, так же как и различных программ. Говоря о программах, можно в качестве примера привести целый дистрибутив - GoboLinux - который следует именно этим приоритетам: отдельный каталог на каждую программу. Подход, реализованный в GoboLinux, имеет одну проблему: идея "один каталог на каждую сущность" применяется абсолютно ко всему, включая системные библиотеки и серверное ПО. Также GoboLinux идёт ещё на один шаг вперёд, полностью изменив файловую систему, - я отношу себя к ярым противникам этой идеи.

В свете сказанного, дискуссии об этом ведутся и в сообществах Ubuntu и Debian. Хорошей отправной точкой является статья "Rename Top Directory Names" для Ubuntu. Эта ссылка дублируется на многих сайтах. Также существует очень много черновых набросков на launchpad.net (web-приложение для разработки Ubuntu). Их действительно так много, что вы замучаетесь перечитывать их. Во многих из них речь идёт об упрощении структуры каталогов системы, следствием чего должно стать упрощение установки ПО.

Что не правильно в GoboLinux?

Я не думаю, что подход, использованный в GoboLinux, является выигрышным, и этому есть две причины:

Четыре шага для решения проблемы

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

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

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

В-третьих, необходимо улучшить предложенное решение; это очень трудно, поскольку здесь необходимо соблюдать баланс между недостаточным и чрезмерным планированием. Также потребуется кто-то, кто будет координировать дискуссию и сможет довести её до окончательного решения. В тайне я мечтаю о том, чтобы этим занялся кто-то из Canonical или Red Hat.

И в-чертвёртых, решение нужно реализовать. Это самая сложная часть. Я уверен, что в ходе реализации обнаружатся различные проблемы, ограничения, и много всего прочего.

Моя "полутехническая" точка зрения

Вот моя идея. Я уже очень давно не программировал на Си, и это значит, что я могу ошибаться. Тем не менее, я уверен, что в состоянии предложить неплохой отправной пункт.

Нужно подготовить исчерпывающий список библиотек и их версий, которые должны быть доступны в операционной системе. Сегодня существует немало настольных систем GNU/Linux, так что у нас есть довольно чёткое представление о том, что требуется. Этот список должен включать как Gnome, так и KDE. Это должен быть "кросс-дистрибутивный" список. Чтобы его подготовить, какой-нибудь дистрибутив (может быть, Ubuntu?) мог бы создать что-то подобное, а потом присоединились бы и остальные. Каждые два года или около того могла бы выходить новая "версия" этой супер-системы с обновлённым списком библиотек и версий. Заметьте, что приложения должны безупречно работать не только в текущей системе, но и в предыдущей версии. Это может означать, что более новые приложения должны быть способны работать на системах четырёхлетней давности.
Следует располагать хорошо продуманным деревом каталогов, содержащим всё приложение. Оно может включать в себя: 1) исполнимые файлы; 2) иконку; 3) каталог lib с дополнительными библиотеками, не входящими в упоминавшийся выше список; и 4) всё остальное. Этот каталог должен быть доступен только на чтение. Он должен иметь расширение .apx и содержать файл application.xml.
В том случае, если нужные библиотеки предоставляются программой, система должна добавить их в путь поиска библиотек перед системными. Так, если какая-то программа потребует определённую библиотеку, отсутствующую в первом месте, или по каким-то причинам будет нужна иная версия имеющейся библиотеки, тогда:
- файловый менеджер GNU/Linux отобразит те каталоги и их иконки;
- вы сможете создавать различные каталоги для разных версий исполнимых файлов и библиотек, соответствующих вашему процессору.
Операционная система должна отслеживать имеющиеся приложения (каждый каталог с расширением .apx и файлом application.xml должен рассматриваться как приложение) и их размещение. Это можно легко осуществить с помощью триггеров ядра (подсистемы inotify - прим.перев.), когда файл перемещается или копируется. Система должна позволять иметь две различные копии одного и того же приложения в разных каталогах.
Операционная система должна предлагать способ обновить все существующие приложения (поскольку будет знать, что и каких версий размещается на диске).
Должна существовать система безопасности, чтобы каждый, кто распространяет приложение, мог "подписать" его - пользователи должны иметь возможность просмотреть подпись прежде, чем запустить приложение. Эта система должна быть расширяема по мере необходимости.
Дистрибутив в своём менеджере пакетов должен предоставлять возможность полностью скрыть любое пользовательское приложение. Yum/apt-get/synaptic и тому подобные приложения должны использоваться также и для обновления системы, а не только пользовательских программ.
Должна существовать "система рецептов" подобно доступной в GoboLinux [Recipies, инструкции по сборке ПО из исходных кодов, аналог системы Ports во FreeBSD или Portages в Gentoo - прим.перев.], гарантирующая, что собранная программа будет работать в своём собственном каталоге. В этом плане чрезвычайно полезно присмотреться к GoboLinux. Обратите внимание на то, что предоставление работающих "рецептов" для каждой программы - это огромная работа, но здесь можно ограничиться пользовательскими программами.

Каждый, кто будет руководить разработкой такой системы, должен внимательно присмотреться к OS X, поскольку инженеры OS X решали эту же самую проблему - и решили её успешно.

Итоги

Эта статья может произвести революцию - а может стать ещё одной статьёй, просто предъявляющей претензии к процессу установки программ в GNU/Linux.

У меня есть мечта. Мечта о мире, где люди распространяют приложения как связанные каталоги, и эти "связки" работают в Ubuntu, Fedora и т.д. И они продолжают работать, когда устанавливается новая версия операционной системы. О мире, где установка программ в GNU/Linux выполняется очень легко и приложениями можно обмениваться простым копированием на флешку.

Надеюсь, что когда-нибудь я увижу всё это в GNU/Linux...

P.S. Некоторые скажут: "Если тебе нравится подход, реализованный в OS X, так и используй OS X". Мой ответ будет таким: "Мне нравится подход, реализованный в OS X, он работает, он решает проблемы, но давайте лучше вдохновимся им и сделаем его ещё лучше".

Текущее положение дел