Установка программ в Linux из исходных кодов

Установка софта из исходников имеет
некоторые положительные моменты, но и
немало отрицательных.

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

Отрицательные:
* Вам придётся самим отслеживать все зависимости для установки программы
* Если что-то пойдёт не так, рассчитывать придется только на помощь разработчиков софта

Перед установкой
Прежде чем устанавливать софт из исходников, убедитесь, что подходящего пакета в Вашем
дистрибутиве нет.

Убедитесь, что в системе установлены средства разработки – компилятор, библиотеки и заголовки для разных пакетов (многие дистрибутивы выделяют их в отдельные пакеты), для компиляции некоторых программ нужны и исходники ядра. Убедитесь, что символическая ссылка linux в директории /usr/src указывает на исходники того ядра, под которым будет бегать установленная программа.

Получение исходников
Закачиваем исходники. Здесь обычно есть два варианта:
1. Закачать готовый архив в формате tar.gz
2. Взять файлы с CVS репозитория. В CVS обычно находится софт "в процессе разработки", более свежий, но и менее протестированный.
Инструкции по пользованию CVS-репозиториями обычно находятся на сайте разработчика.

Распаковываем тарболы. Это можно сделать при помощи любого графического архиватора (например File Roller в Гноме), или же из консоли:
* для архива '.tar.gz':
tar xvzf имя.архива.tar.gz
* для архива '.tar.bz2':
tar xvjf имя.архива.tar.bz2

Затем перемещаемся в распакованный таким образом каталог и внимательно читаем, что написано в файлах README и INSTALL. Этот шаг абсолютно необходим. Без него ничего работать не будет.
Если софт получен из CVS-репозитория, читаем инструкции разработчика на сайте по "бутстрапанию" (см. http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29) пакета, если необходимо.

Конфигурирование и компиляция
Если инструкции требуют запуска скрипта с названием configure в качестве первого шага, сначала прогоняем
./configure --help

и внимательно читаем, какие опции можно послать скрипту configure для правильного конфигурирования программы.
Затем запускаем
./configure

с выбранными опциями. На этом этапе программе могут понадобиться зависимости, которые либо не установлены в нашей системе, либо не найдены скриптом configure. В первом случае, их надо найти и поставить, во втором -- еще раз исследовать опции скрипта configure на предмет указания ему места, где искать нужные зависимости.

Если configure сработал нормально, запускаем make.
Здесь тоже возможны варианты. Если make завершается ошибкой, копируем ошибку в окошка ГУГЛА и смотрим, как наши товарищи по несчастью справились с подобной ошибкой. Иногда решения нет, и надо писать разработчику.

Установка

Если make прошел нормально, мы почти у цели.
Думаете, теперь надо прогонять make install? В сущности, можно и так (не забудьте стать рутом для этого).
Но Правильный Путь™ заключается в том, чтобы сделать теперь из скомпилированного исходника пакет для нашего дистрибутива и поставить его средствами штатного менеджера пакетов.

Создание пакета

checkinstall
Это одна из немалого количества программ для построения пакетов из исходников. Она не дистроспецифична и генерирует пакеты для самых распространённых пакетных менеджеров (в отличие от paco, который тоже всем хорош, кроме того, что держит свою базу пакетов).
В классической схеме сборки приложения из исходников, использующих automake (./configure && make && make install)', эта утилита заменяет собой 'make install. Делая в принципе то же самое, но при этом регистрируя устанавливаемую программу в пакетной базе дистрибутива.
checkinstall -R

Построит и установит RPM пакет(для Fedora, Mandriva, SuSe, Alt, ASP...)
checkinstall -D

Создаст и установит DEB-пакет(для Debian, Ubuntu...)
checkinstall -S

Создаст и установит TGZ-пакет(для Slackware, Zenwalk, DeepStyle, Vektorlinux, Mops; в поставке дистра есть checkinstall, патченный самим Патриком...)

Имя пакета по умолчанию будет myNewUtil.
Версия: 1.2.3. После запуска checkinstall всегда просит ввести описание пакета, а также даёт возможность изменить имя, версию и т.д.

makepkg
Ещё раз просмотрите опции configure на предмет префикса, куда устанавливается программа. Обычно это /usr или /usr/local.

Создаем в домашней директории нашего пользователя директорию foo, а в ней – директории usr и usr/local
Теперь становимся рутом и пишем
make install prefix=/home//foo/usr/local
cd foo
makepkg foo.tgz

В результате получаем Слакварный пакет, который можно теперь установить программой installpkg.

Система портов ABS в ArchLinux
В ArchLinux существует свой механизм сборки программ из исходников - система портов ABS. Каждый порт содержит файл с набором правил для загрузки архива с исходниками и сборки пакета PKGBUILD и дополнительные файлы, если требуется (например, патчи). Все ПО в ABS распределено по репозиториям (current, extra, community, testing, unstable) и категориям (multimedia, office, x11, etc.). Т.е в корне дерева портов ABS располагаются каталоги с репозиториями, внутри которых - каталоги с категориями пакетов (каталоги с категориями репозитория current расположены в самом корне дерева). Для обновления дерева используется простая команда 'abs', без всяких ключей (только для ее работы потребуется пакет cvs, потому
что порты ABS распространяются именно с помощью этого механизма). Чтобы найти порт требующейся программы, достаточно выполнить в консоли:
find /var/abs -name имя_пакета

Что требуется для сборки пакета?
Ничего мудреного - переходим в каталог с портом нужной программы и в консоли выполняем 'makepkg'. Что делает makepkg:
1. Проверяет, нет ли уже собранного пакета в директории сборки (или в директории, в которую указано складывать собранные пакеты, указывается в файле /etc/makepkg.conf). Если уже есть, то выкинет ошибку, обойти это можно, если запустить makepkg с ключом '-f'
2. Проверяет зависимости программы, указанные в PKGBUILD.
Если чего не хватает - укажет, чего придется поставить.
3. Проверяет наличие архива с исходниками и дополнительных файлов (makepkg складывает их в /var/cache/pacman/src ), если нет, то скачивает его по адресам, указанным в PKGBUILD.
4. Проверяет контрольные суммы скачанных файлов, если они указаны в PKGBUILD
5. Распаковывает архивы с исходниками
6. Выполняет действия, указанные в секции 'build' в PKGBUILD - какие-либо дополнительные действия (например, наложение патчей) и собственно сборку.
7. Если сборка проходит успешно, 'makepkg' устанавливает программу в директорию 'pkg' в корне директории порта и упаковывает эту директорию в стандартный pkg.tar.gz-пакет. Все,
пакет собран. Теперь его можно установить:
pacman -A имя_пакета.pkg.tar.gz
В ArchLinux есть также пользовательский репозиторий пакетов AUR. На AUR лежат те же порты, из которых собираются программы в ABS.
Для установки программы с AUR есть два пути:
Первый:
1. Заходим на http://aur.archlinux.org , находим нужную нам программу.
2. Скачиваем PKGBUILD, создаем каталог с именем, в точности соответствующим названию пакета, указанного в PKGBUILD (желательно в /usr/abs, дабы не замусоривать систему).
3. Выполняем makepkg, устанавливаем pacman'ом ,как было указано выше.
Второй:
1. Устанавливаем программу
2. Ищем программу на AUR, выполнив

qpkg -a имя_нужной_программы

3. Выполняем
qpkg -p имя_нужной_программы

(эта команда сама скачает PKGBUILD, исходники, соберет программу в пакет и установит ее).

Создание собственного пакета в ArchLinux
(На случай, если даже в AUR его не нашлось).
Как было сказано, для построения пакета в Арче нужен PKGBUID файл.
Разложим его по полочкам.
Прежде всего стоит отметить, что, чтобы не захламлять дерево ABS собственными пакетами, лучше выделить для этого отдельный каталог (у меня - /var/abs/local), в этом каталоге создаем подкаталог, где, собственно, все и будет происходить. Копируем туда файл ''/var/abs/ PKGBUILD.proto'' (прототип, который есть в дереве ABS) и переименовываем его в "PKGBUILD". Далее нужно подправить файл. Сначала нужно подправить описание пакета:
*'pkgname' - название пакета,
*'pkgver' – версия пакета,
*'pkgrel' – версия сборки,
*'url' – обычно домашняя страница приложения,
*'license' – лицензия, под которой выпускается приложение,
Далее следует указать зависимости, конфликты и источник исходников собираемого пакета:
*'depends' – список зависимостей пакета, названия должны быть заключены в одинарные кавычки и разделены пробелами. Если важна версия зависимости – ее можно указать
(например, kdelibs>=3.5.1),
*'makedepends' – список пакетов, необходимых на этапе сборки (например, если пакет собирается какой-нибуть нестандартной системой сборки типа cmake),
*'conflicts' – список пакетов, с которыми может конфликтовать собираемый
*'replaces' – список пакетов, которые заменяет собираемый,
*'backup' – список файлов, которые необходимо будет сохранить при установке собираемого пакета,
*'install' – имя установочного скрипта (в нем – дополнительные шаги, необходимые для завершения установки пакета),
*'source' – указывает путь, откуда будут забираться исходники пакета.
Если для сборки необходимо несколько файлов (например, дополнительные патчи), их указывают через пробел,
*'md5sums' – md5 суммы скачанных исходников. Если не заполнять эту строчку, ничего страшного не произойдет, makepkg лишь обратит на это внимание. Кстати, makepkg может сгенерировать эти контрольные суммы и добавить их в PKGBUILD. Для этого необходимо выполнить
makepkg -g >> PKGBUILD

Далее следует скрипт сборки, который представляет собой все те действия, которые пришлось бы выполнить, если пакет собирался бы вручную. Обычно это стандартная последовательность
./configure && make && make install
однако здесь стоит обратить внимание на префикс, куда будет устанавливаться пакет и опции скрипта ./configure.
Теперь о флагах 'makepkg'.
Об '-f' уже говорилось, еще два полезных флага – это '-c', очищающий каталог пакета после сборки и '-i', который позволяет сразу же установить собранный пакет.

rpmbuild
Cтандартная утилита для сборки программ из исходников и упаковки их в пакеты rpm во многих пакетных дистрибутивах, построенных на базе RedHat.
Для сборки бинарного пакета обычно используются пакеты *.src.rpm, содержащие сами архивы с исходниками программ, дополнительные файлы (патчи, desktop-файлы и т.д.) и spec-файл – набор правил для сборки программы.
Итак, если нужно собрать в пакет rpm какую-нибудь программу, выполняем следующее:
*1. Качаем файл *.src.rpm для нашей программы (обычно их можно найти на
ресурсах http://rpmfind.net, http://rpm.pbone.net или в репозиториях дистрибутива (если он ориентирован на rpm-пакеты) ).
*2. Устанавливаем его:
rpm -ivh имя_пакета.src.rpm

В каталоге /usr/src/rpm/SOURCES должен появиться архив с исходниками нужной нам программы, а в каталоге ''/usr/src/rpm/SPECS - файл 'имя_программы.spec''' (это файл, описывающий правила сборки).
*3. Переходим в директорию /usr/src/rpm/SPECS и там выполняем:
rpmbuild -bb –target=архитектура_процессора название_программы.spec
(запускаем сборку программы)
Вместо "архитектура_процессора" подставляем архитектуру процессора, под которую собираем пакет(в большинстве случаев подойдет i686 ), 'название_программы.spec' - это ''spec-файл'' для нашей программы. Если не удовлетворены какие-то зависимости, 'rpmbuild' скажет об этом – тогда придется доустановить недостающие пакеты.
*4. Если все пройдет удачно, на выходе получим rpm-пакет нашей программы, он будет лежать в ''/usr/src/rpm/RPMS/архитектура_процессора_под_которую_собирался_пакет''. Переходим в эту директорию и оттуда делаем:
rpm -ivh имя_программы.rpm

Все, программа установлена.

Иногда бывают случаи, когда файла src.rpm нет или нам нужно внести поправки в процесс сборки/установки программы. В этом случае придется править (или создавать заново) spec-файл. spec-файл состоит из 8 частей:
*1. Заголовок. В заголовке есть несколько стандартных полей:
**'Summary:' - однострочное описание пакета.
**'Name:' - строка имени из имени файла rpm
**'Version:' - номер версии пакета
**'Release:' - номер релиза пакета
**'Icon:' - имя файла иконки, которое будет использоваться другими высокоуровневыми утилитами установки (подобными Glint)
**'Source:' - указывает место расположения файлов исходных текстов, а также различных доп. Файлов (файлов конфигурации, скриптов и т.д.) (таких полей может быть несколько: (Source0, Source1.. ), все эти файлы должны располагаться в /usr/src/rpm/SOURCES (если исходники ставятся из src.rpm-файла, то rpm их сам туда кидает)
**'Patch:' - Это место, где вы можете найти заплатки, если вы захотите загрузить их снова. (Как и в поле 'Source:', эти файлы должны лежать в ''/usr/src/rpm/SOURCES'' ), таких полей может быть тоже несколько: Patch0, Patch1...
**'Copyright:' - авторские права (GPL, BSD, MIT, public domain, distributable, или commercial)
**'BuildRoot:' - задает корневую директорию для построения и установки нового пакета, (обычно ''/usr/src/rpm/BUILD/имя_пакета'' )
**'Group:' - указание высокоуровневым программам установки (таким как Glint) где расположить программу в их иерархических структурах.
**'BuildRequires:' - указываются зависимости пакета, их версии (этих полей может быть несколько )
*2. Описание пакета (не обязательно)
( '%description' )
*3. Здесь указываются разные подготовительные действия (распаковка архивов, наложение патчей и т.д.)
( '%prep' )
*4. В этом разделе указываются все действия, необходимые для сборки программы(например, выполнение скрипта ./configure, make и т.д.)
( '%build' )
*5. Действия, необходимые для установки пакета (на этапе сборки пакета программа устанавливается в BuildRoot )
( '%install' )
*6. Действия для очистки результатов сборки(удаляется каталог BuildRoot), (выполняются, если запустить rpmbuild с ключом '--clean')
( '%clean' )
*7. Здесь располагается список фалов, которые будут включены в бинарный rpm пакет (исполняемые файлы, man-страницы, файлы конфигурации и т.д.
( '%files' )
*8. Changelog программы (не обязательно)
( '%changelog' )

Stow
Stow – это программа управления пакетами, которая держит их на "отдельных полочках" (например /usr/local/stow/emacs но ''/usr/local/stow/perl'' ) и в то же время "делая вид", что они установлены в одном и том же месте (/usr/local).Почитать мануал по Stow можно здесь.
Stow - это скрипт на Перл, который не будет запинаться, если у вас установлен Perl 5.005 и выше. Его надо установить перед установкой самой Stow.
Пример использования Stow.
Предположим, нам нужно установить 'abc-1.4', и у нас есть 'abc-1.4.tar.gz', и его нужно установить в /usr/local/bin. После распаковки
tar -zxvf abc-1.4.tar.gz

переходим в созданный каталог 'abc-1.4'
cd abc-1.4

Сначала нам нужно установить приложение в каталог stow. Пусть это будет /usr/local/stow.
Произведём рутинные шаги по установке:
[root@linuxbox abc-1.4]# ./configure --prefix=/usr/local/stow/abc-1.4
[root@linuxbox abc-1.4]# make
[root@linuxbox abc-1.4]# make install

Далее, нам нужно "положить на полочку" приложение, и создать симв. Ссылки внутри целевого каталога, т.е. ''/usr/local/bin'', с помощью stow. Эти операции можно проводить из-под юзера.
[userX@linuxbox abc-1.4]$ cd /usr/local/stow/
[userX@linuxbox stow]$ stow -t /usr/local/bin abc-1.4

Приложение 'abc-1.4' теперь расположилось в своём каталоге, abc-1.4, внутри каталога stow, а
соответствующие ему ссылки – в целевом каталоге, /usr/local/bin.Если нам понадобится перекофигурировать или апгрейдить приложение 'abc-1.4', мы можем просто произвести соответствующие изменения в его собственном каталоге, а после этого снова "положить на полочку", обновив соответствующие символические ссылки:
[userX@linuxbox stow]#$ stow -R abc-1.4

Для удаления приложения, нам нужно будет просто "убрать с полочки" 'abc-1.4':
[userX@linuxbox stow]#$ stow -D abc-1.4

Stow просто удалит символические ссылки, указывающие на установленное приложение и никогда не удалит самих установочных файлов. Таким образом, остаётся возможность позже снова "поставить на полочку" приложение с помощью stow