LXF104:Что за штука
|
|
|
Что за штука... 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
