Кроем одежку: Самостоятельная сборка и оптимизация KDE4 и GNOME3KDE и GNOME развиваются просто сумасшедшими темпами, предлагая пользователю новый функционал, улучшенную стабильность и устранение ошибок. Но путь релиза в репозитории дистрибутивов, как правило, долог: мэйнтейнер собирает пакет, всесторонне тестирует его, и только после одобрения он попадает в основной репозиторий. А попробовать новую версию хочется уже сейчас. Подготовка для сборкиНе все исправления и нововведения доходят до нас очень быстро. Например, на момент написания этих строк была доступна версия KDE SC 4.6.2, а в официальном репозитории Ubuntu 10.10 значилась только 4.5.1. Аналогичная ситуация и в репозиториях других дистрибутивов и операционок — openSUSE 11.4, Gentoo Linux, FreeBSD, OpenBSD и т.д. Есть, конечно, и другие причины для самостоятельной сборки. В пакете из репозитория могут быть активированы не все функции или возможности, которые хотелось бы использовать в работе. Или обнаружена ошибка, которая мешает нормально юзать программу или открывает брешь в системе. Еще вариант: сборка получилась тяжеловесной, в ней присутствуют ненужные приложения, и появилось желание ее чуть «подрезать», чтобы сэкономить системные ресурсы. В общем, причины у каждого свои. Поэтому сегодня рассмотрим, как самостоятельно собрать свои версии KDE и GNOME. Все операции будем производить на Linux Mint 10 с рабочей средой GNOME. В других дистрибутивах процесс практически полностью аналогичен. Для экспериментов рекомендую создать новую учетную запись, в которой и проводить тестирование. Иначе при первом запуске могут быть внесены изменения в профиль, и залогиниться со старой версией не удастся. Кстати, подобную рекомендацию могу дать и тем, кто юзает несколько дистров с общим /home. Еще один немаловажный момент — пользователь должен получать доступ к sudo. Для этого — включаем его в группу admin (в Linux Mint). Далее настраиваем среду сборки. Разработчики приготовили рекомендации и скрипт ~/.build-config, устанавливающий необходимые глобальные переменные (clck.ru/BZTg) и настройки для ~/.bashrc. Некоторые параметры внутри закомментированы, следует внимательно их просмотреть и определиться с их необходимостью. Например, при сборке в 64-битной системе надо обязательно установить:
Чтобы не собирать kdesdk, комментируем строку «alias make=makeobj». Аналогично определяемся, нужна ли пересборка PyKDE4 и DBUS. Обращаем внимание и на «function cmakekde», в которой определены параметры сборки при помощи cmake. Так, по умолчанию компиляция производится с параметрами:
Числовой параметр после флага '-j' определяет количество потоков и обычно выбирается по формуле (X+1), где Х — число CPU. Если устанавливаются разные версии KDE или варианты сборки, достаточно изменить путь $KDEDIR. Упростить весь процесс можно при помощи скриптов kdesrc-build (kdesrc-bld.kde.org) и build-tool. Первый разрабатывается в рамках комьюнити KDE и более популярен. Предварительная настройка, в том числе выбор модулей для установки, производится при помощи конфигурационного файла ~/.kdesrc-buildrc. В архиве есть пример, копируем его и правим.
Параметров внутри предостаточно. Новичкам я бы посоветовал начать с изучения этого файла, это снимет впоследствии много вопросов. Да, и не забудь установить переменную:
Модули настраиваются в конструкциях:
Теперь запускаем:
Скрипт самостоятельно скачает исходники, настроит среду, соберет, установит и протестирует результат. Поддерживается несколько дополнительных параметров, так, чтобы повторно не загружать файлы, добавляем '--no-svn'. Для теста конфигурации используем '--pretend', в этом случае будут проверены все установки без выполнения процедуры загрузки и сборки. И, наконец, '--refresh-build' подчистит временные файлы, чтобы можно было начать процесс сборки повторно. Для работы kdesrc-build понадобятся установленные Perl и libwww. Надо сказать, потребуется много места на харде. Так, для сборки qt-copy, kdesupport, kdelibs, kdepimlibs, kdebase нужно около 7 Гб, но я бы выделил не менее 20 Гб на временные файлы и готовую среду. Дополнительные компоненты — это еще плюс несколько гиг. Получаем исходникиЧтобы более тонко настроить KDE, лучше провести ручную сборку без средств автоматизации. Все действия рекомендуется производить в подкаталоге ~/kde. В ~/kde/src закачиваем исходные тексты, а в ~/kde/ build будет размещена готовая сборка. К слову, указанные ранее сборочные скрипты устанавливают алиасы cs и cb, упрощающие быстрый переход в указанные каталоги. Если подключен репозиторий kubuntu-ppa/backports, то можно просто ввести:
В процессе позволяется выбрать оптимизацию под определенный тип процессора.
Сборка при этом будет проведена с параметрами, указанными в /etc/apt/apt-build.conf. Такой подход, как правило, предоставляет нам мало возможностей по оптимизации, но зато пакеты впоследствии легко обновить. При помощи apt часто удобнее просто вытащить исходники и, главное, зависимости для сборки:
Список пакетов, необходимых для корректной установки, очень большой. И кроме стандартных инструментов сборки, таких как buildessential, cmake, doxygen, в нем присутствует множество заголовочных файлов разных приложений и библиотек. Некоторые из зависимостей необязательны, но впоследствии во время сборки может оказаться, что не активирован какой-то элемент. Например, если не установлен libxine-dev, KDE будет сконфигурирован без поддержки мультимедиа. Сам проект предлагает Git репозитории (quickgit.kde.org) и тарбалы (ftp.kde.org/pub/kde). Доступен и SVN, но его поддержка прекращается. Поэтому создаем файл:
И закачиваем. Минимум, что потребуется, это:
Если нужен больший функционал, то ставим kdemultimedia, kdeartwork, extragear и любые другие приложения и плагины. Также могут понадобиться исходники Qt. Здесь два варианта. KDE'шный, с параметрами оптимизации, подобранными под KDE, багфиксами и т.п.
Или Gitorious, предлагающий «чистый» Qt или патченный:
Если ранее были сделаны изменения в ~/.bashrc и ~/.build-config, о которых говорилось выше, переходим в каждый образованный подкаталог и последовательно даем команду:
Здесь лучше написать простенький скрипт, который автоматизирует процесс:
Сборка KDE производится при помощи cmake, команда ./configure, к которой все привыкли, здесь не используется. Все дополнительные параметры задаются непосредственно в строке запуска cmake или путем правки вспомогательных скриптов CMakesLists.txt и файлов с расширением *.cmake. Практически в каждом подкаталоге можно найти подобные настройки. Внутри описывается множество параметров, причем значительная часть из них, к тому же, прокомментирована. Разобравшись, можно легко подключить или отключить сборку модуля или подкомпонента, расширив или, наоборот, урезав функционал. Например, функции add_subdirectory() и add_ optional_subdirectory() в CMakesLists.txt задают список загружаемых и используемых при сборке зависимостей. Потихоньку обходя все подкаталоги, определяем модули, которые следует включить или отключить. Конечно, многие функции затем можно деактивировать уже в рабочей системе, но если стоит вопрос уменьшения веса и нагрузки, то решение лучше принять сейчас. На слабых системах можно убрать поддержку семантического десктопа strigi и nepomuk, kdepim-приложения. Если видеокарта не тянет, то убираем поддержку эффектов в KWin и OpenGL полностью. На нетбуке удаление Akonadi обеспечит прирост во времени загрузки чуть ли не на 20% плюс меньшее потребление ресурсов. Кроме того, можно убрать совместимость с KDE3, сегодня в этом уже нет острой необходимости. Также можно убрать флаги raster и trace при сборке qt-gui, это сразу облегчит Х, как минимум, на 30 Мб. На этом этапе преимущество получают гентушники: достаточно изменить USE-флаг (gentoo.org/dyn/use-index.xml) — и дело в шляпе, в других дистрах исходники придется рыть самому. К слову, последние стейджи в Gentoo используют XZ-сжатие, в итоге — архивы с KDE4 тянут на 200 Мб меньше (1,8 Гб против 2 Гб). Кроме того, можно пойти на более радикальные меры. Например, вместо kwin использовать openbox-подобный оконный менеджер. Сейчас находится в активной разработке Antico, представляющий собой Qt4/X11 оконный менеджер + рабочий стол (как KDE+KWin). Он не связан с kdelibs, а потому легкий и не нагружает систему. Главное, что он позволяет использовать многие приложения из KDE. Минус — текущая версия 0.2 пока сыровата и содержит минимум функций. Загрузить Antico можно из Git:
Обеспечиваем загрузкуЧтобы вместо GDM использовать KDM, просто прописываем «/usr/ sbin/kdm» в /etc/X11/default-display-manager. Теперь осталось занести в ~/.xsession или ~/.xinitrc строку «startkde» и зарегистрироваться в системе. В дистрибутивах, базирующихся на Debian, общесистемными являются файлы в /etc/alternatives. Среди них x-window-manager является симлинком на оконную среду, а x-session-manager — менеджером сеанса. Для выбора нужной среды в окне регистрации можно создать файл /usr/share/xsessions/kde4.desktop примерно такого содержания:
Сборка GNOME3К мажорным релизам сборщики дистрибутивов относятся настороженно, ведь первые версии, как правило, сыроваты, да и не содержат всех функций. Исправления и более полноценную среду GNOME мы получим уже скоро вместе с обновлением 3.2. Чтобы пользователи могли сразу же познакомиться с новой версией, сразу после анонса было предложено два Live-дистрибутива: на базе openSUSE и Fedora (gnome3.org/tryit.html). Сейчас третий гном доступен во всех свежих релизах этой весны — openSUSE 11.4, Ubuntu 11.04 Natty Narwhal и Fedora 15. Те, кто работают в ранних версиях системы или дистрибутивах, вроде Linux Mint, могут подключить PPA-репозиторий «GNOME 3 Stack».
Запускаем командой:
Или просто выходим и регистрируемся повторно, выбрав GNOME3. Но хочу предупредить, что на момент написания этих строк там была самая первая сборка, и в Linux Mint она не работала должным образом. При помощи APT мы можем вытянуть и исходные тексты для самостоятельной перекомпиляции. Сам проект предоставляет в открытый доступ Git-репозиторий (git.gnome.org) и FTP-сервер с архивами (ftp.gnome.org/pub/GNOME). Для сборки среды GNOME и приложений используется специальный скрипт на Python — JHBuild (developer.gnome.org/jhbuild). Забираем последнюю версию из Git и устанавливаем обычным образом (потребуется пакет gnome-common): Для корректной работы JHBuild требует, чтобы переменная PATH содержала подкаталог ~/.local/bin.
Настройка параметров сборки производится в конфигурационном файле ~/.jhbuildrc. В архиве есть готовый пример, который берем за основу.
Файл разделен на несколько секций, где описываются репозитории, устанавливаемые модули, каталог для установки, флаги оптимизации. Полный список модулей можно найти на специальной странице live.gnome.org/Jhbuild/Modulesets. Модули устанавливаются рекурсивно, то есть, если для работы одного из них потребуется другой, тот будет собран автоматически. В простейшем случае файл выглядит так:
После настройки набираем:
Программа создаст необходимые для работы каталоги и проверит наличие утилит, используемых при сборке. Здесь есть нюанс: запускать jhbuild от имени рута нельзя, поэтому все рабочие подкаталоги и прочие действия, требующие привилегий администратора, придется выполнять вручную, затем повторно вводить «jhbuild sanitycheck». Все зависимости описаны в документе live.gnome.org/JhbuildDependencies и доступны в репозитории любого дистрибутива (минимум это: m4, Perl, Python и GCC). Я бы рекомендовал использовать именно его, впоследствии не будет проблем с обновлениями, и другие программы будут «видеть» установленные таким образом пакеты. Хотя предлагается альтернативный вариант — просто использовать параметр bootstrap:
Если sanitycheck показал, что все нормально, можно переходить к следующему шагу:
Теперь JHBuild загрузит, соберет и установит все описанные в ~/.jhbuildrc модули. Очень удобно, что в случае ошибки на любом этапе сборки скрипт не заканчивает работу, а выводит меню, позволяющее выбрать дальнейшее действие (пропустить, повторить, сконфигурировать и т.п.). С помощью JHBuild можно собрать и отдельное приложение или библиотеку:
ЗаключениеКак видишь, в самостоятельной сборке KDE4 и GNOME3 нет ничего сложного. Разработчики проектов позаботились о продвинутых (и нетерпеливых) пользователях, подготовив вспомогательные инструменты. Конечно, некоторое время следует потратить на изучение настроек в конфигурационных файлах, но результат оправдает ожидания.
|