Как-то раз я решил скачать "cuyo" (смотрите в этом выпуске обзор http://www.linuxgazette.com/lg74/orr3.html Mik'а Orr'а) -- новую игру, о которой упоминалось в рассылке Answer Gang admin. Однако, зайдя на веб-сайт, вместо пакета для установки я нашёл только тарболл с исходными файлами, хотя в письме упоминалось, что должен иметься архивный пакет для Debian. "Ничего сложного," -- подумал я -- "я делал это и раньше..."

[Пакет cuyo .deb есть в нестабильной ветви дистрибутива Debian. Но эта статья применима к любой программе, которая либо не входит в ваш дистрибутив, либо версия дистрибутиве устарела или неадекватна, но которую вы, тем не менее, хотите установить. -Iron.]

Для тех, кто не знает: тарболл -- это заtarенный и, как правило, заgzipенный набор исходных файлов, из которых можно скомпилировать в программу; обычно файловое имя тарболла либо "progfile-1.23.tgz", либо "progfile-1.23.tar.gz", где "progfile" - это название программы, а "1.23" (разумеется, числа могут быть любыми) соответствует номеру версии. Когда вы устанавливаете пакет -- неважно, RPM, DEB или что-то другое, используемое в вашем дистрибутиве, -- вы просто помещаете библиотеки, документацию и уже откомпилированный бинарный файл(ы) в соответствующие каталоги. Компиляция исходных файлов -- это работа, которую обычно выполняют для вас люди, сопровождающие пакет (мэйнтейнеры).

После того, как я скачал тарболл в свой подкаталог "/home/ben/TGZs", специально созданый мною для хранения скачанных тарболлов, я скопировал его в "/tmp" -- мне нравится компилировать исходные файлы там. Кстати, некоторые предпочитают это делать в "~/tmp" - подкаталоге своего домашнего каталога: причина в том, что "/tmp" обычно очищается во время загрузки, а компиляция, преведшая К ДЕЙСТВИТЕЛЬНО СЕРЬЕЗНОЙ ошибке может "подвесить" машину... что потребует перезагрузки (о-опс!). Не берусь опровергать эту точку зрения, но сам продолжаю оставаться чертовски рисковым парнем -- я доверяю своему Linux. :)

Файл назывался "cuyo-1.03.tar.gz" - поэтому соответствующей магией, превращающей его обратно в полезные файлы, будет

tar xvzf cuyo-1.03.tar.gz

Эта команда создаст каталог с именем "cuyo-1.03" прямо в "/tmp".

(Вообще-то, я сделал не совсем так -- я зашёл внутрь тарболла с помощью Midnight Commander'а, открыл во второй панели "/tmp" и нажал "F5", чтобы скопировать сжатый каталог. Я привел здесь это заклинание для тех, кто хочет или вынужден проделывать всё это вручную.)

Учтите, что некоторые авторы программ не столь любезны при сборке своих тарболлов: иногда такое расtarивание приводит к копированию всех файлов в текущий каталог. Страшная путаница, особенно, если это ваш домашний каталог! Несколько дюжин файлов перемешиваются с вашими, в придачу к ним кучка каталогов -- а уж если если имена некоторых файлов совпадут с именами ваших файлов... (не то, что ваши файлы будут заменены, но все равно путаница ещё та) или каталогов (пакет будет скопирован в них, и вам потом нужно будет всё это вычищать). Как примитивно! Вот почему я люблю заходить в тарболлы и копировать вместо обычного разtarивания. Те, кто не использует Midnight Commander или другой файловый менеджер, могут заглянуть внутрь тарболла просто выполнив команду

tar tvf <filename>

Вы увидете содержимое архива, и берегитесь, если перед именем каждого файла не стоит имя каталога! Ну, конечно, не так всё страшно: всё, что вам нужно сделать -- создать каталог (если вы дадите ему имя тарболла "progname", то потом вы не забудете, что там находится) и расtarить файл внутрь него.

mkdir rudeprogram-6.66
tar xvf rudeprogram-6.66.tgz -C rudeprogram-6.66

Теперь все файлы из тарболла "rudeprogram" будут извлечены в указанный подкаталог.

К счастью, автор "cuyo" был культурным товарищем (как и большинство авторов программ), и "cuyo" был заtarен прямо в собственном подкаталоге. Внутри был набор файлов, включая те, которые вы должны изучить перед началом работы: "README" и "INSTALL". В первом обычно содержатся авторские инструкции, рекомендации и т.п. Второй -- достаточно стандартный, в нём объясняется работа скрипта "configure", весьма крутой программы, обычно создаваемой утилитой "autoconf", которая изучает вашу систему и корректно (ну, почти корректно) создает Makefile, необходимый для сборки программы. Огромное преимущество этого метода в том, что если автор был внимателен при написании своей программы, "configure" создаст правильный Makefile для любой версии Unix и, возможно, даже для других OS.

Позвольте мне на минутку отвлечься: некоторые программы настолько просты, что не требуют "configure", а поставляются просто с Makefile (его имя может начинаться с большой буквы или полностью пишется строчными). Другие -- ещё проще, всё, что вы увидите -- это один единственный "progfile.c" или "progfile.cc". Для них, в первом случае нужно просто выполнить "make", а во втором -- "cc progfile.c -o progfile".

Как бы то ни было, я запустил "configure" в подкаталоге "cuyo" -- он немного "пожевал" мою систему, что является его работой, и создал Makefile. Что могло быть лучше? :) Хотя была небольшая проблема - "configure" во время работы выводит сообщения и предупреждает вас в случае отказов (обычно останавливаясь и печатая ошибку.) Сообщение, которое он мне выдал, правда, без остановки, было такое:

checking the Qt meta object compiler... (cached) failure
>configure: warning: Your Qt installation seems to be broken!

Хм-м. Ну он же всё-таки сделал makefile. Обычно нефатальные ошибки просто означают, что вы не получите каких-либо возможностей программы, но её всё-ещё можно скомпилировать. Давайте попробуем.

Я запустил "make" -- просто в командной строке набрал "make" -- который по умолчанию читает "Makefile" (или "makefile") и выполняет команды, соответствующие цели "all" и тут...

О-опс. Он обвалился.

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

Итак. Мы смело продолжаем. Когда я сказал, что он обвалился, что конкретно я видел? Ну, "make" должен выполняться без ошибок. Иногда -- часто -- вы будете получать предупреждения, но это другое -- просто библиотеки у вас могут слегка отличаться, или, возможно, ваш компилятор несколько более строг к объявлениям -- обычно это не фатально. Ошибки, из-за которых вы вываливаетесь из компиляции до ее завершения -- вот их то мы и должны исправить. Вот как это выглядело:

Baldur:/tmp/cuyo-1.03$ make
make all-recursive
make[1]: Entering directory /tmp/cuyo-1.03'
Making all in src
make[2]: Entering directory /tmp/cuyo-1.03/src'
c++ -DHAVE_CONFIG_H -I. -I. -I.. -DPKGDATADIR=\"/usr/local/share/cuyo\"
-Wall -ansi -pedantic -c bildchenptr.cpp
In file included from bildchenptr.h:21,
  from bildchenptr.cpp:18:
  inkompatibel.h:13: qglobal.h: No such file or directory
make[2]: ** [bildchenptr.o] Error 1
make[2]: Leaving directory /tmp/cuyo-1.03/src'
make[1]: [all-recursive] Error 1
make[1]: Leaving directory /tmp/cuyo-1.03'
make:  * [all-recursive-am] Error 2
Baldur:/tmp/cuyo-1.03$

Начало ошибки начинается со строки "In file included..." и заканчивается (по крайней мере, та часть, которая нам нужна) словами "...qglobal.h: No such file or directory". Понятно, не хватает заголовочного файла. Я быстренько просмотрел дерево исходных файлов "cuyo", чтобы проверить, что автор не забыл включить один из собственных файлов (да, бывает) -- ничего. Видимо, это один из моих -- так и есть, программа должна найти файл, поставляемый с библиотекой, которую я должен был иметь в своей системе для компиляции программы. Хмм. А какая? Разумеется, та, которая содержит "qgloval.h".

В моей системе есть несколько скриптов, которые помогают мне в работе со стандартыми задачами установки. Один из них - "pkgf" - он ищет нужный мне файл во всём дистрибутиве Debian и сообщает, в каком пакете этот файл находится. (Это не то же, что "dpkg -S <file>", который делает это только для установленных пакетов). Если вы используете Debian, то сможете получить такую же функцию, скачав текущий "Packages.gz" с <ftp://ftp.debian.org> и zgrepпнув в нём (поискать с помощью утилиты zgrep) имя файла, или просто сходите на <http://www.debian.org/Packages> и воспользуйтесь их утилитой поиска. Смысл в том, чтобы найти пакет с "qglobal.h" и установить его.

pkgf "qglobal.h"
usr/include/qt/qglobal.h  devel/libqt-dev
        devel/libqt3-emb-dev
        devel/libqt3-dev
        devel/libqt-emb-dev

Так, так - похоже, мне нужно выбирать из нескольких пакетов. Хорошо, "libqt3-dev", вроде, самый последний:

apt-get install libqt3-dev

Установка прошла достаточно быстро, и... я снова получил ту же ошибку, когда ещё раз запустил "make". То же будет и у вас. Поэтому, не делайте так. Не следует забывать (а я знал, что будет ошибка -- я это сделал, чтобы привлечь ваше внимание), что вы уже выполнили "./configure" и старые (неверные) значения всё ещё содержатся в Makefile, а также в нескольких других файлах, поэтому, вместо того, чтобы впустую тратить время на выяснение, где они могут быть, сделайте так:

ben@Baldur:/tmp/cuyo-1.03$ cd ..
ben@Baldur:/tmp$ rm -rf cuyo-1.03
ben@Baldur:/tmp$ tar xvzf ~/TGZs/cuyo-1.03.tar.gz -C .
ben@Baldur:/tmp$ cd cuyo-1.03

Другими словами, я просто целиком "снёс" каталог "cuyo" и заменил его свежей копией исходных файлов. Это хорошее правило: при сомнениях вернуться к первоначальным исходным файлам. Верите или нет, я научился этому трюку от корабельного механика, который необычно хорошо справлялся со своей работой. Кенни изложил его такими словами: "верни все к заведомо рабочему состоянию и начинай оттуда". Я не видел, чтобы его совет не сработал; известно, что клиенты склоны вопить, когда ты говоришь, что должен удалить часть засоренного софта, стоящего в данный момент, и устанавливать с нуля... но, немного погодя, слышишь: "Э-э, а этот парень неплохо все сделал". Так можно потерять часть сделанной работы -- у меня так бывало -- но, как Кенни, я не хочу, чтобы моё имя стояло на барахле.

Знаю, знаю -- я говорю на общие темы, а не о старой доброй установке тарболла. Суть в том, что надо понимать "философию" того, чем вы собираетесь заниматься, и лучше понять методологию и особенности работы до того, как вы начнете реально что-либо делать. Хорошо, вернёмся к главному вопросу -- программа заработала или нет???

ben@Baldur:/tmp/cuyo-1.03$ ./configure
<No errors>
ben@Baldur:/tmp/cuyo-1.03$ make
<lots of output elided>
make[2]: Leaving directory /tmp/cuyo-1.03/src'
Making all in data
make[2]: Entering directory /tmp/cuyo-1.03/data'
make[2]: Nothing to be done for all'.
make[2]: Leaving directory /tmp/cuyo-1.03/data'
Making all in docs
make[2]: Entering directory /tmp/cuyo-1.03/docs'
make[2]: Nothing to be done for all'.
make[2]: Leaving directory /tmp/cuyo-1.03/docs'
make[2]: Entering directory /tmp/cuyo-1.03'
make[2]: Nothing to be done for all-am'.
make[2]: Leaving directory /tmp/cuyo-1.03'
make[1]: Leaving directory /tmp/cuyo-1.03'
ben@Baldur:/tmp/cuyo-1.03$

Ураааа!!! Ошибок нет -- и когда я вошёл в каталог "cuyo-1.03/src", там был очень миленький бинарничек под названием "cuyo". Теперь, если я хочу продолжить установку (а не просто посмотреть, понравится ли мне игра), мне надо ввести

make install

Будет прочитан Makefile и выполнятся все команды для цели "install", которые, скорее всего, установят бинарник(и), страницы man и документацию. Однако у меня есть склонность сначала поиграться с программой и посмотреть, нравится ли она мне, поскольку в большинстве тарболлов make-файлы не содержат цель "uninstall" (по-моему, это стыдно, ведь это сделало бы тарболл-пакеты почти такими же лёгкими в установке и удалении, как, скажем, RPM или DEB).

Перечислим всю процедуру установки тарболла:

1. Проверить, содержит ли он каталог или файлы просто (как некультурно!) свалены в него.
2. Разtarте в каталог "/tmp" или "~/tmp"
3. Выполните "configure", если он есть.
4. Выполните "make" или, в случае единственного простого "file.c" или "file.cc", команду "cc".
5. Выполните "make install", если результат получился тот, что вы ожидали.

Это почти всё. Обратите внимание, что я не обсуждал здесь вопросы безопасности (действительно ли вы доверяете автору этого тарболла или пакета? Никогда не заходите рутом, чтобы поиграться с бинарником, ладно?), ни многие другие аспекты, касающиеся системного администрирования -- эти аспекты очень важны и необходимы, однако, не рассматриваются этой короткой статье. Мудрый системный администратор -- а это, мой дорогой домашний пользователь Linux, вы, больше за вашей машиной никого нет! -- должен много читать, размышлять, пытаясь проникнуть в суть происходящего, и принимать мудрые решения.

Удачи, и да будут все ваши зависимости разрешены. :)

Ben Okopnik

Ben Okopnik

Кибер-техник всех мастей, Ben удивляет мир на своёй 38-футовой яхте, строя сети и хакая хардвер и софтвер, когда у него кончаются деньги на круиз. Он игрался и работал на компьютерах ещё во времена Elder'а (кто-нибудь помнит Elf II?) и не собирается прекращать в ближайшее время.

Copyright (C) 2002, Ben Okopnik.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 74 of Linux Gazette, January 2002

Команда переводчиков:

Владимир Меренков, Александр Михайлов, Иван Песин, Сергей Скороходов, Александр Саввин, Роман Шумихин

Со всеми предложениями, идеями и комментариями обращайтесь к Сергею Скороходову (suralis-s@mtu-net.ru)

Сайт рассылки: http://gazette.linux.ru.net
Эту статью можно найти на http://gazette.linux.ru.net/lg74/articles/rus-okopnik.html