Материал из Linuxformat.

Что за штука... RPM5

Считаете управление пакетами одним из самых скучных аспектов Linux? Кажется, и здесь назревают перемены. Пол Хадсон сообщает подробности…

• Да это просто перевод страниц: я и сам знаю, что такое RPM. Это Red Hat Package Manager, он распоряжается пакетами в Red Hat. Ну что, продолжим?

Поразительные познания! Только речь идет не о RPM, а о RPM 5.

• Он что, в пять раз лучше, что ли?

В пять не в пять – но он определенно лучше, и открыт для перемен.

• Перемены? Да ведь менеджер пакетов обязан быть оплотом стабильности!

Тут вы ошибаетесь. RPM – кстати, менеджер не только для Red Hat, но и для Mandriva, SUSE, PCLinuxOS и многих других дистрибутивов – раздвоился.

• Как раздвоился?

Red Hat Package Manager разделился на два проекта. Свободное ПО потому и свободное, что каждый может взять любой исходный код, модифицировать его и свободно опубликовать. Так случилось и с RPM: теперь над менеджером работают две группы программистов, и каждая разрабатывает свою версию.

• Не нравится мне это…

Судить рано. Возможно три исхода: ветвь проваливается (все остаются при старом RPM), побеждает (все переходят на RPM 5), или обе ветви сосуществуют. Меня лично устроил бы один из первых двух вариантов.

• А разве не лучше мирное сосуществование? Пользователь сам выбирал бы, что для него лучше, не полагаясь на разработчиков!

Да, вы правы. Но, получив RPM-файл, откуда вы узнаете, к какой версии он относится? У нас и так слишком много путаницы вокруг инсталляции чего-либо в Linux – tar-архивы, Deb-пакеты, скрипты и прочее – а тут еще две параллельные и несовместимые версии RPM!

• Об этом я как-то… Зачем же они разделились?

Беда в том, что RPM был написан более 10 лет назад, и большая часть кода с тех пор почти не менялась. RPM попросту тяжел на подъем, и ведущий разработчик, Джефф Джонсон [Jeff Johnson], взялся его исправить. В результате, некоторые операции RPM 5 проводит в 10 раз быстрее RPM 4, а поддержка устаревших спецификаций RPM 3 прекращена.

• На первый взгляд, изменений не так уж много. А как с совместимостью двух форматов?

А никак. Джонсон переписал базовый формат RPM, добавив некоторые дополнительные функции (например, LZMA-сжатие и специализированные тэги). Новый RPM предназначен для работы и на Unix-подобных системах, отличных от Linux, включая BSD, Solaris, Mac OS X и Cygwin/Windows. Джонсон считает, что реформы вроде RPM 5 возникают лишь раз в 10 лет. Иначе говоря, годами сохранять совместимость – это здорово, но, решившись порвать с прошлым, нужно рвать по всем фронтам – ради стабильности следующего десятилетия.

• А почему бы всем дистрибутивам сейчас же не перейти на RPM 5?

Может случиться и такое. Но RPM 5 был разработан без участия http://www.rpm.org, официального сайта разработчиков RPM, вот в чем проблема. Сайт RPM5 (http://www.rpm5.org) именует себя «домашним сайтом менеджера пакетов RPM», что граничит с нахальством, поскольку http://www.rpm.org продолжает работу над кодом «классического» RPM.

• Похоже, типичный случай изобретательской ревности…

Red Hat недвусмысленно заявила, что не собирается переводить на RPM 5 ни Fedora, ни Red Hat Enterprise Linux, и в обозримом будущем будет продолжать работу с командой http://www.rpm.org.

• Но если новая версия в 10 раз быстрее, зачем цепляться за пережиток прошлого?

Red Hat заботится о своих корпоративных клиентах. Среди условий контракта с RHEL – семилетняя поддержка и прочная обратная совместимость, а переход с RPM 4 на пока неофициальный RPM 5 может вызвать серьезные проблемы у заказчиков, которые превыше всего ценят именно стабильность.

• Novell, вероятно, то же думает, со своими-то настольными решениями для предприятий…

Novell пока помалкивает. Red Hat была просто вынуждена реагировать быстро, речь-то идет о ее собственном менеджере пакетов!

• А что если команда RPM 5 просто возьмет да и отдаст весь свой код RPM 4?

RPM 5 – такое же свободное ПО, как и RPM 4, поэтому разработчики и так отдают свой код всем, кому он нужен. На самом деле, группа RPM 5 пристально следит за списком рассылки RPM 4 и включает самые интересные заплатки в свой код. В результате, на базовом уровне RPM 5 обладает всей функциональностью RPM 4, плюс добавляет собственные разработки. Маловероятно, что RPM 5 бросит затею и уступит RPM 4 – мне кажется, скорее http;//www.rpm.org в итоге перейдет на RPM 5, приняв его за официальную версию.

• Почему вы так думаете?

Такое уже бывало. Возьмите хоть случай с GCC: в 1997 году, когда разработка GCC забуксовала, группа программистов отделилась и приступила к созданию EGCS (Experimental GNU Compiler System, экспериментальной системы компиляции для GNU). Дело пошло значительно быстрее, и спустя два года команда GCC признала: «Ладно, ребята, EGCS луч- ше – пускай будет новым GCC» – на том и порешили. В конце концов, разработчики открытого ПО – люди конструктивно ленивые: если они видят, что у кого-то здорово получилось, они просто берут это и пользуются.

• Ну, тогда двойные усилия по разработке двух версий RPM уже вроде и не зря затрачены.

Конечно, особенно в дальней перспективе. В ближайшем будущем разрыв между ветвями RPM, вероятно, будет углубляться. Если один из небольших гибких RPM-дистрибутивов (например, PCLinuxOS) решится попробовать RPM 5 – а я этому не удивился бы – дистрибутивы разделятся относительно RPM на два лагеря, неизбежно вызвав путаницу. А прекратится путаница лишь после полного перехода всех дистрибутивов на новый формат, что, учитывая длительный период обновления версий, например, у Red Hat Enterprise Linux, может растянуться на годы.

• Годы? А где можно узнать подробности, чтобы основательно подготовиться и пережить предстоящую бурю?

Пока реальные дискуссии идут только на сайте RPM 5, http://www.rpm5.org. Домашняя страница RPM 4 (истинно официальный сайт RPM) – http://www.rpm.org. Нам же пока остается наблюдать за RPM-дистрибутивами – поживем, увидим… LXF