Опираясь на исходники или Source Based-дистрибутивы Linux

, Домашний компьютер (#12, 2002)

На страницах этого выпуска вы, надеюсь, уже прочитали о нескольких дистрибутивах Linux, часто столь разных, что возникает вопрос: а одна ли это операционная система? Тем не менее, кроме ядра и базового инструментария, их объединяет еще и то, что все они суть дистрибутивы пакетные. То есть образованные из уже откомпилированных разработчиками программ, т. н. бинарных пакетов. Что, конечно, избавляет владельца системы от необходимости заниматься этим самому, но, с другой стороны, лишает его многих степеней свободы - ведь у ряда программ столько опций сборки, что разработчикам дистрибутивов волей-неволей приходится останавливаться на некоем усредненном варианте, ориентированном на среднестатистического пользователя.

Для преодоления такого насилия над свободой воли можно прибегнуть к другой крайности - скачать из Сети исходники ядра, базовых утилит, средств компиляции, общесистемных библиотек и собирать систему, что называется, с нуля. И такие системы действительно собираются - проект "Linux с нуля" (Linux from Scratch, www.linuxfromscratch.org) тому пример. Однако это не дистрибутив в собственном смысле слова, а, скорее, набор инструкций по сборке, для которой, ко всему прочему, требуется наличие уже установленной системы.

Но, как всегда, нашелся и третий выход - так называемые Source Based (то есть базирующиеся на исходниках) дистрибутивы. Идея их пришла в Linux из параллельного мира BSD-систем, конкретно - из FreeBSD. В которой испокон веку утвердилась концепция "портов".

Суть ее - из прекомпилированных бинарных пакетов устанавливается только самый необходимый базовый минимум системы, как то: ядро, средства загрузки системы, набор системных и прикладных утилит и инструментарий для компиляции программ. А заботу о расширении функциональности берут на себя порты - сумма инструкций, позволяющая нечувствительно для пользователя получить из Сети исходники необходимых программ (и, главное, всех компонентов, связанных зависимостями с заказанными), произвести их адаптацию под конкретную систему, скомпилировать и должным образом установить собранное в древе файловой системы. Причем - с обязательной регистрацией установленного в специальной базе данных, что позволяет, помимо прочего, вчистую удалить установленную программу, если такое желание возникнет.

В Linux идея портов получила дальнейшее развитие. Так, в дистрибутиве Gentoo (www.gentoo.org) реализована система porteges, весьма близкая к BSD-прототипу. После установки прекомпилированных базовых компонентов (в ходе которой настраивается, в частности, сетевое соединение и задается оптимизация под конкретный процессор) для инсталляции любого дополнительного приложения, от простейшего текстового редактора до оконной системы X, следует перейти в каталог /usr/portege, выбрать среди тематически сгруппированных программ нужную, перейти в ее подкаталог (например, /usr/ portege/app-editors/nano-xxx) и дать простую команду emerge с указанием имени portege, в данном примере

$ emerge nano-xxx

По этой команде (/usr/bin/emerge), являющей собой довольно сложный, но доступный для понимания скрипт на языке Python, выполняются следующие действия:

• соединение с официальным сервером этой программы или одним из его зеркал (список которых может быть отредактирован);

• скачивание исходных текстов на локальную машину (в каталог /usr/portege/distfiles);

• наложение, в необходимых случаях, патчей и конфигурирование исходников с опциями, требуемыми для нормальной работы в данной системе;

• компилирование программы, причем - с оптимизацией под процессор, указанный в ходе первичной установки;

• инсталляция исполняемых модулей программы и всех необходимых компонентов, типа библиотек, документации и т. д.

Если в ходе конфигурирования исходников или их сборки выясняется, что для установки данной программы необходим какой-то компонент, отсутствующий в системе (например разделяемая библиотека), для него отыскивается собственный portege и происходит его установка по той же схеме (скачивание - конфигурирование - компиляция - размещение).

В дистрибутиве Sorcerer (http://sorcerer.wox.org) и происходящих от него (а таковыми являются SourceMage (www. sourcemage.org) и Lunar Linux (www.lunar-linux.org), в оправдание названия, все гораздо проще: для установки программы достаточно, находясь в любом месте файловой системы, произнести (пардон, набрать в командной строке) волшебное слово cast, сопроводив его шаманским заклинанием spell. В качестве заклинания выступает просто имя программы из числа зафиксированных в соответствующей базе данных. А дальше - все тем же порядком, что и в Gentoo. Есть и меню-ориентированный механизм управления установкой программ, также обладающий волшебными свойствами - sorcery. Одно из таких свойств - возможность полной перекомпиляции базовых компонентов (в том числе и предустановленных) системы с учетом их новейших версий (и, разумеется, с оптимизацией под процессор), получаемых с официальных сайтов.

Передать впечатление от работы любой системы портирования невозможно - нужно видеть и испытать на себе (вернее, своей машине). Впервые опробовав в деле порты FreeBSD, я долго ходил в состоянии, близком к эйфории. И любой пакетный дистрибутив, даже такой, как Debian или ALT Linux с их apt (не в обиду им сказано), стал казаться мне неуклюжим и статичным.

Все это, конечно, очень благородно, скажете вы мне. Но не требует ли такое благолепие постоянного подключения к сети? Отвечаю: да, Source Based дистрибутивы во всей красе проявляют себя именно при постоянном коннекте, причем быстром и устойчивом. Однако любой из исходников может быть развернут и на машине с модемным подключением, и даже без такового вообще: достаточно в принципе иметь выход в Сеть. Например, все потребные исходники можно скачать на службе (желательно - за казенный счет), притащить домой и поместить в соответствующий локальный каталог. Причем даже не обязательно рыскать по сотням и тысячам ftp-серверов: исходники всех портированных программ продублированы на сайтах разработчиков дистрибутивов.

А как быть с вычислительными мощами? - можете задать провокационный вопрос. И не потребует ли компиляция, скажем, 40 Мбайт исходных текстов системы X на стареньком Celeron'е времен, сопоставимых с возрастом Метагалактики? Да и диск мигом будет забит архивами исходников, результатами их распаковки, промежуточными продуктами компиляции и прочим мусором (для развертывания Sorcerer, например, рекомендуется дисковый раздел в 8 Гбайт - и это без пользовательских данных).

Все учтено могучим ураганом - отвечу я неверующим. И любая из упомянутых систем портов способна не только устанавливать программы, но и генерировать из исходников бинарные пакеты (в формате компрессированных архивов *.tar.bz2, то есть очень компактных), которые легко установить на любой другой машине, как и в пакетных дистрибутивах. С той разницей, что пакеты будут включать только нужные вам компоненты, причем оптимизированные и настроенные, как нужно для целевой машины. То есть пакеты собираются на службе на двухпроцессорном Xeon'е с гигабайтами ОЗУ и терабайтами дискового пространства, а устанавливаются дома на Pentium-166 (причем в оптимизированном под последний виде).

Конечно, развертывание дистрибутивов-исходников потребует несколько большей подготовки, чем инсталляция Mandrake в автоматическом режиме, и времени. Однако последнее компенсируется получением идеально оптимизированной "под себя" системы. А относительно первого - и Gentoo, и Sorcerer сопровождаются столь подробными и внятными инструкциями по установке, что разобраться в них способен любой, знающий о существовании дисковых разделов и умеющий читать (правда, по-английски). Да, понадобится еще и умение писать (вернее, "давить батоны"): некоторые действия по настройке, кириллизация, например, потребуют ручной правки конфигурационных файлов. Однако и в этом ничего суицидального нет - такие действия многократно описаны.

И последний вопрос из серии провокационных: если всё так хорошо, то почему дистрибутивы-исходники не стоят на каждом пользовательском десктопе? А вот это я могу объяснить только их молодостью и, как следствие, недостаточной известностью в народе. Надеюсь, данная статья поспособствует преодолению этого их недостатка. Правда, следует учесть еще одно: поработавшему в Gentoo или Sorcerer будет мучительно больно вернуться на любой самый распрекрасный Red Hat

Процесс, именуемый компиляцией программ, или, по нашему, сборкой, может показаться далекому от программирования пользователю весьма таинственным. Однако при корректно, я бы даже сказал - вежливо написанном исходнике (а таких - большинство, и далее речь пойдет только о них), ничего страшного в нем нет. И в случае, если программа написана не именно под Linux или FreeBSD, а под некий абстрактный Unix.

Перво-наперво по получении исходника его следует распаковать и перейти в образовавшийся каталог. В нем обнаруживаются файлы README и (или) INSTALL, объясняющие (правда, как правило, по-английски - вне зависимости от подданства и национальной принадлежности разработчиков) порядок дальнейших действий. Каковые совершаются в три этапа. Первый - конфигурирование, то есть приведение программы в соответствие с реалиями конкретной системы, фиксируемой файлом Makefile. Оно выполняется командой ./configure, которая находится в каталоге с исходниками (почему в ней и фигурируют символы ./). Если такого файла там нет - значит, программа столь проста, что в конфигурировании не нуждается (поскольку случай невежливости мы исключили), и можно сразу переходить ко второму этапу, а именно, - собственно сборке, осуществляемой программой make или, в некоторых случаях, make all, что должно быть оговорено в упомянутых выше файлах; впрочем, система X, например, собирается командой make World. И последний этап - установка, то есть помещение собранных компонентов куда следует, что достигается командой make install. Особо вежливые разработчики предусматривают и четвертый этап - команду make uninstall для бесследного удаления программы...

Процесс сборки завершается безошибочно (случай с ошибками не рассматриваем - при их появлении следует или бросить дело, или разбираться в деталях, а это совсем другая история). И в итоге получается исполняемая программа с некими предопределенными ее автором настройками. Что, в сущности, идентично результату установки прекомпилированного пакета из дистрибутива - только там эти настройки заданы разработчиком последнего. Суть же самостоятельной сборки - именно индивидуальные настройки под себя, не так ли? И тут начинается самое интересное.

Некоторые настройки задаются на стадии конфигурирования. И тут обычно чтения README мало - следует для начала запустить ./configure с опцией -help, конечно же, вежливо предусмотренной автором. Она выводит некий список доступных опций, в котором почти всегда присутствуют (и чаще всего требуются) опции --prefix=каталог, --bindir=каталог, --with/--without или --enable/--disable. Смысл первых двух - в размещении программы (или только ее исполнимого файла) в каталоге, отличном от предопределенного, каковым по умолчанию почти всегда выступает /usr/local. Например, при сборке командной оболочки, выступающей как пользовательская (login shell), желательно, чтобы ее исполнимый файл находился в каталоге /bin. А опции типа with и т. д. используются для разрешения/запрещения какой-либо особенности. Например, я всегда запрещаю употребление консольной мыши (в Midnight Commander, браузере links и т. д.) как указательного устройства - функции копирования/вставки с ее помощью для меня важнее, нежели возможность щелкать ею по пунктам меню.

Другие настройки указываются непосредственно при компиляции. В частности, именно здесь можно потребовать оптимизации под конкретный процессор, задать ее уровень, предписать экстремальные формы оптимизации и множество других параметров, чье точное (и осознанное) использование требует, как минимум, изучения руководства Ричарда Столлмена сотоварищи по gcc. Заниматься этим - лень. И вот тут на помощь приходят системы портирования Source Based-дистрибутивов. Они берут на себя заботу о настройке как на стадии конфигурирования, так и сборки. Причем опции и того, и другого могут быть настроены глобально, для всех программ (например, экстремальная оптимизация под Pentium 4), или изменяться для отдельных их групп. А лучшие из таких систем позволяют и ручное вмешательство в процесс на любом его этапе.