2002 г
За годы, прошедшие со времени перворазмещения этой заметки, проект портирования портежей Gentoo на FreeBSD то умирал, то гальванизировался. Вновь. Как обстоит с ним дело сейчас - не знаю. Да и выяснять, честно говоря, лень. Так что пусть эта заметка будет достоянием истории.
Разговоры о переносе инфраструктуры портежей Gentoo Linux на иные операционки идут достаточно давно. В списке претендентов на портежирование (не путать с протезированием) портежей - и MacOS с ее свободным аналогом Darwin, и вечно эмбриональный Hurd, и BSD-системы в разных своих ипостасях. И вот - свершилось, на GWN от 1 сентября прошло сообщение о первом работоспособном переносе портежей на Open- и FreeBSD, осуществленном Grant Goodyear (транскрибировать фамилию не рискну).
За подробностями предлагается обратиться на >страницу Гранта. Но прежде, чем это сделать, подумаем - а за каким вообще нужно переносить портежи в Open- или, тем более, во FreeBSD?
Действительно, каждая из этих систем имеет свою систему портов, основанную на тех же принципах, что и портежи Gentoo (вернее - как раз наоборот, идея портежей в Gentoo была заимствована из BSD-мира). И если коллекция портов OpenBSD выглядит несколько ограниченной, то во FreeBSD она недавно достигла 10000 - то есть включила в себя почти весь открытый и свободный софт, когда-либо созданный человечеством.
Спору нет - порты FreeBSD (а именно в недрах этой ОС зародилась концепция сборки программ из исходников, а не инсталляции прекомпилированных их пакетов) очень удобны, просты в обращении (так как основаны на универсальном механизме make-файлов) и, главное, проверены временем. Единственное, чего в них недостает - возможности глобальной настройки взаимозависимостей пакетов.
Описанные в make-файлах системы портов зависимости определяются майнтайнером данного порта, исходящим из своих представлений о том, какие дополнительные опции нужны (или - не нужны) данной софтине по умолчанию. И если его представления не совпадают с таковыми пользователя - последнему придется выполнить индивидуальное конфигурирование каждой собираемой программы. Последнее - не сложно, и выполняется теми же стандартными with/without и enable/disable, что и при ручной сборке. Однако, согласитесь, при большом количестве устанавливаемых программы весьма скучно было бы в командной строке запрещать для всех изначально консольных приложений поддержку Иксов...
В системе же портов Gentoo этой цели служит специальная переменная USE, определяемая в нескольких файлах конфигурации, каждый из которых имеет определенный приоритет по отношению в другому (подробнее - в документации на Gentoo.ru. И если в файле /etc/make.conf (наиболее приоритетном) явным образом задать
USE="-X -gnome -kde"
то можно быть уверенным в том, что впредь все программы, не требующие использования Иксов и не предназначенные для запуска исключительно в KDE или GNOME, будут собираться без поддержки этих систем. Разумеется, если поддержка эта для данного пакета опциональна - понятно, что на жесткие зависимости никакие значения переменной USE влияния не оказывают.
Вторая важная особенность портежей Gentoo - то, что она пронизывает систему насквозь, от ядра и системных утилит его обрамления до распоследнего пользовательского приложения. То есть установка (или обновление) базовых компонентов (того, что во FreeBSD именуется Distributions) осуществляется точно тем же методом, что и установка, скажем, Иксов или KDE. Во FreeBSD же процесс "перестройки мира" (make world) оторван от инсталляции портированных программ (хотя и то, и другое контролируется механизмом make-файлов).
Система портежей имеет еще несколько отличий от своего прототипа. Например, там есть возможность включения в единый портеж нескольких, в том числе и несовместимых, версий одного пакета (например, Gtk-1.x и Gtk-2.x, первая и вторая линии freetype, и так далее), для чего предназначен механизм слотов (SLOTS). Во FreeBSD же в таких случаях приходится создавать отдельные порты. Сказанного, думаю, достаточно, чтобы поверить в осмысленность процесса переноса портежей в BSD-системы вообще и во FreeBSD в частности. Хотя чисто для эксперимента - заработает ли?
Нужно заметить, что это - не первая попытка переноса инфраструктуры какого-либо Linux-дистрибутива в BSD-мир. Не так давно аналогичное действо было предпринято в рамках проекта Debian (сколько бы не говорили про то, что Debian GNU/Linux - это операционка GNU проекта Debian на ядре Linux, на сей момент практически Linux'ом она и исчерпывается). А именно, механизм apt-get, вместе с многочисленным инструментарием проекта GNU, был портирован на ядра Free- и NetBSD.
Смысл этого деяния для меня (и, судя по обсуждению на Opennet.ru, для многих других) остался не совсем ясным. Ну, о достоинствах или недостатках самого apt'а распространяться не буду: если по сравнению с чистым rpm'ом это действительно прогресс, то порты FreeBSD все равно (это сугубо личное мнение) много более универсальны, гибки, удобны и, не в последнюю очередь, прозрачны для пользователя.
Однако главная сила всех BSD-систем всегда была в неразрывном единстве ядра, системных и пользовательских утилит - то есть того же Distributions. И подменять в нем юзер-уровень FreeBSD аналогичным Linux'овым кажется, как минимум, опрометчивым (тем паче, что низкоуровневые утилиты неизбежно наследуются от материнской системы).
Однако вернемся к Гранту и его детищу. В отличие от Debian'овского портирования, он не пытается подменить BSD-инструментарий Linux'овым. Разумеется, для функционирования механизма портежей ему пришлось инкорпорировать в дерево файловой системы *BSD кое-какие GNU-утилиты. Однако, во-первых, он сам классифицирует это как хак и рассматривает в качестве временной меры. Во-вторых, утилиты эти не замещают одноименные BSD'шные, мирно с ними сосуществуя.
В упомянутом выше >GWN содержался призыв протестировать детище капитана Гранта. Пройти мимо этого призыва я не смог, так что делюсь своими впечатлениями. Для чего отправился на >его страницу и, после прочтения сопроводительных текстов, скачал файл >gentoo-fbsd.tgz. Попутно рядом можно увидеть несколько собранных бинарных пакетов GNU-утилит и BSD-специфичных портежей (включая ядро и libc), но о них мы пока говорить не будем.
Далее, понятное дело, потребовался достаточно свежий тарбалл дерева портежей (я воспользовался версией portage-20030822.tar.bz2). Курочить свою установленную FreeBSD с не вполне предсказуемым результатом мне не хотелось, так что я инсталлировал ее заново - на отдельном слайсе (к сожалению, выделить под это хозяйство диск не получилось).
Установлена была FreeBSD 5.1 RELEASE с мини-диска (то есть не содержащего Иксов и packages). Устанавливал я ее, понятно, в минимальной комплектации - только Base и Crypto из Distributions (меньше некуда), и не особо утруждая себя настройками. Затем, перезагрузившись, в соответствие с рекомендациями Гранта, создал группу portage и одноименного пользователя (хотя, похоже, это не обязательно). Далее - переход в корневой каталог и распаковка скачанного архива:
$ cd / ;
$ tar xzvf /path/gentoo-fbsd.tgz
После этого можно видеть, что в файловое древо FreeBSD добавились (в каталоги /bin и /usr/bin) оболочка bash и кое-какие утилиты - GNU-версии sed, tar, make, patch. Причем, дабы они не путались с одноименными программами изначальной FreeBSD, все они получили в своем имени префикс g - /bin/gsed, /bin/gtar, /usr/sbin/gmake и так далее.
Собственно система управления портежами - программы emerge, ebuild и прочие, - локализовались в каталоге /usr/lib/portage/bin (символические на них ссылки оказались и в /usr/sbin). Что немаловажно, в каталог /etc добавились профильные файлы /etc/make.conf (подменивший оригинальный Free'шный), /etc/make.globals и прочие, описывающие условия сборки.
Теперь можно было дать команду
$ emerge info
и убедиться, что условия сборки программ из портежей волшебным образом встроились во FreeBSD.
Настало время развернуть собственно дерево портежей. Перейдя предварительно в каталог /usr, даю команду
$ tar xjvf /path/portage-20030822.tar.bz2
Грант рекомендует выполнить вместо этого процедуру
$ emerge sync
с целью получения наиболее свежего снапшота (благо соответствующий инструментарий в лице rsync сотоварищи также устанавливается при развертывании его тарбалл). Однако мне показалось ленивым качать по модему 10 Мбайт. И, как оказалось в последствие, сошло и так...
Последнее подготовительное действие - дополнение базы данных портежей (/var/cache/edb) сведениями о виртуальной библиотеке glibc (в реальности она не устанавливается):
$ echo virtual/glibc sys-libs/glibc >> /var/cache/edb/virtuals;
$ emerge inject sys-libs/glibc-2.3.2
Все, можно начинать установку портежей. Для начала неплохо бы отредактировать файл /etc/make.conf в соответствие со своими пожеланиями. Чтобы проделать это с максимальным комфортом, я решил установить свой любимый joe - чисто для эксперимента, не развалится ли все:
$ ebuild usr/portage/app-editors/joe/joe-2.9.8.ebuild merge
Разумеется, дабы не качать исходники из сети, они предварительно должны быть помещены в /usr/portage/distfiles. Все прошло замечательно - команда
$ joe /etc/make.conf
позволила выполнить настройку в привычной среде.
В умолчальном файле /etc/make.conf, предлагаемом Грантом, заслуживают внимания следующие момент. Значение переменной USE дано в форме
USE="-*"
то есть все опциональные зависимости при сборке пакетов исключаются. Далее, дается только общее описание хоста:
CHOST="i686-pc-linux-gnu"
а флаги C и C++ закомментированы. Тем не менее я рискнул дать их в рекомендуемой для Gentoo Linux (но не FreeBSD) форме:
CFLAGS="-march=pentium4 -O3 -pipe"
CXXFLAGS="${CFLAGS}"
Наконец, переменная FEATURES имеет значение -sandbox. Грант объясняет это тем, что пакет это в BSD-системах не собирается.
После этого я навскидку попробовал установить несколько пакетов, не отягощенных излишними зависимостями (тех, исходники которых я смог уместить на свой небольшой экспериментальный BSD-раздел). Одни (например, zsh) установились с полпинка, другие (типа links) устанавливаться отказались. Однако в первом приближении система показала себя работоспособной. По крайней мере, ошибок компиляции из-за завышения флагов оптимизации отмечено не было.
Таковы первые впечатления о первом опыте инкорпорации Gentoo-портежей во FreeBSD. И - краткий предварительный итог. Проект переноса портежей во FreeBSD, не смотря на сугубо экспериментальный характер, кажется мне весьма значимым. Во-первых, это один из реальных примеров влияния Linux'овых идей на BSD-мир (до сих пор, как мне кажется, воздействие шло в основном в обратном направлении).
Во-вторых, в случае успеха этого проекта мы получаем прототип универсальной системы управления пакетами (согласно Гранту, инкорпорация портежей в OpenBSD проходит столь же безболезненно), которая может настраивать любую ОС Unix-клана (вплоть до MacOS). Что даст дополнительный стимул для развития свободного софта вообще.
Сообщения
