"Gazeta do Linux... fazendo o Linux um pouco mais divertido!

"

Instalação de Software desde a Fonte

-ou-
O que faço com este arquivo file.tar.gz?

Por: Ben Okopnik

Traduzido por Jorge Dominguez Chavez (Jodocha)

1 de Abril de 2002, para Gazeta do Linux

O outro dia, eu decidi descarregar o "cuyo" (veja o artigo de Mike Orr neste número), um jogo novo que foi referido na lista
dos admin Do Gangue dos Respostas. Quando eu fui ao sítio na rede, no entanto, só encontrei uma fonte tarball em vez de um
pacote - embora o e-mail tivesse mencionado um arquivo Debian disponível. Nada difícil, pensei - eu fiz isto antes...

[O cuyo .deb está na distribução Debian instável. Mas este artigo aplica-se a qualquer programa que você
queira instalar quer esteja ou não na sua distribuição, ou quando a versão da distribução seja antiga ou
inadequada. -Iron.]

Para aqueles que não sabem, um tarball é uma lista de arquivos fontes "tar" e normalmente "gziped" que podem ser compilados
para criar um programa; o nombe do arquivo de um tarball é normalmente ou "progfile-1.23.tgz" ou "progfile-1.23.tar.gz",
onde "progfile" é o nome do programa e "1.23" (obviamente, os números podem ser quase qualquer coisa) são a versão.
Quando você instala um pacote - seja RPM, DEB, ou qualquer outra distribução - você está simplesmente colocando as
bibliotecas, documentação, e os binários pré-compilados ou binários nos directórios onde eles pertencem. Compilar a fonte é
uma etapa que normalmente é feita para você pelo administrador do pacote.

Depois de carregar o tarball para o meu subdirectório "/home/ben/TGZs", um que eu crie especialmente com a finalidade de
armazenar tarballs descarregados, eu coloquei uma cópia disto em "/tmp", onde compilarei as fontes. Note que algumas
pessoas preferem fazer isto em "~/tmp ", um directório debaixo do seu directório base; a razão para isso é que normalmente
¨/tmp¨ é limpo durante o arranque, e uma compilação que corra REALMENTE mal pode bloquear a sua máquina... o que
requereria uma reinicialização (oops!) Eu não questiono a sua opção, mas pretendo continuar a ser um fulano arriscado - Eu
confio no meu Linux. :)

O arquivo foi chamado "cuyo-1.03.tar.gz" - assim, o pormenor apropriado de magia que torna isto em arquivos úteis é
tar xvzf cuyo-1.03.tar.gz

Isto criou um directório chamado "cuyo-1.03" aí mesmo em "/tmp".

(OK, só que não é exactamente como eu fiz isto; Eu olhei dentro do tarball com o Midnight Commander, abri o "/tmp" no meu
segundo painel, e presionei "F5" para copiar o directório comprimido. Eu estou soletrando isto aqui para aquelas pessoas que
querem ou têm que fazer isto manualmente.)

Note que alguns autores de programas não são tão "corteses" ao compor os seus tarballs: por vezes, ao fazer untarring a pessoa
esvazia a lista inteira de arquivos no directório actual. Isso é uma bagunça, especialmente se está em seu directório base!
Várias dúzias de arquivos misturados com os seus; um bando de directórios, também - e é muito pior se alguns desses têm o
mesmo nome de alguns dos seus arquivos (não que os seus sejam sobrepostos, mas ainda assim é uma bagunça) ou seus
directórios (serão escarregados materiais nele que você terá então de selecionar.) Que rude! Isto é por isso que eu gosto de
espiar em tarballs e copiar, em vez de só fazer untarring por atacado. Para aqueles que não usam o Commander ou outro gestor
de ficheiros que seja capaz de espreitar dentro de uma tarball, basta que faça

tar tvf <filename>

Isto lhe mostrará o seu conteúdo - e se não estiver tudo pré-fixado com um nome de um directório, tenha cuidado! Bem, não
realmente: tudo que você tem de fazer é criar um directório (se você lhe der um nome igual ao do tarball do programa, você
não esquecerá o que é, depois) e faça untar do arquivo dentro disto.

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

Agora, todos os arquivos do tarball do "rudeprogram" serão descarregados para o subdirectório especificado.

1
Felizmente, o autor do "cuyo" é um pessoa cortês (como a maioria dos autores é), e o "cuyo" foi armazenado no seu próprio
subdirectório. Dentro deste, havia a lista de arquivos, inclusive aqules que você deve sempre verificar antes de começar as
operações,: "README" e "INSTALALL". No primeiro normalmente estão as instruções do autor, recomendações, etc. O
segundo é bastante normalizado - é um arquivo que explica as operações do "configure", um programa extremamente útil
normalmente criado por "autoconf" que verifica o seu sistema e correctamente (bem, normalmente) prepara o Makefile, que é
o necessário para compilar o programa. A enorme vantagem disto é que, se o autor tivesse cuidado ao escrever o programa
dele, "configure" criaria o Makefile correcto em qualquer versão de Unix - e talvez até mesmo outros SOs.

Me permita divagar por um momento: alguns programas são tão simples que não requerem "configure", e simplesmente vêm
com um Makefile (estes podem ser capitalizados ou todo letras minúsculas). Outros são ainda mais simples - tudo que você vê
é um único "progfile.c", ou "progfile. cc". Com estes, a compilação consiste em simplesmente correr "make" no primeiro caso,
ou "cc progfile.c -o progfile" no segundo.

De qualquer forma - eu corri o "configure" no subdirectório do "cuyo"; este esteve a mastigar durante algum tempo o meu
sistema, que é seu trabalho e construiu um Makefile para mim. Não é agradável a parte dele? :) Havia um pequeno problema,
apesar disso: o "configure" imprime as mensagens enquanto corre, e o adverte no caso de fracassos (normalmente parando e
imprimindo um erro.) A mensagem que me deu - sem parar, porém - era
checking the Qt meta object compiler... (cached) failure
configure: warning: Your Qt installation seems to be broken!
Hmm. Bem, construiu o makefile, de qualquer maneira. Normalmente, os erros não fatais significam que você não terá
algumas das características do programa, mas ainda compilará. Bem, tentemos.

Eu corri o "make" - só digitando "make" na linha de comando que normalmente só le o "Makefile" (ou "makefile"), e segue os
comandos especificados no objetcivo "all" e,...

Ooops. fracasso.

Foi neste momento que eu decidi escrever este artigo. Eu não tinha pensado em fazer isso; Eu na verdade tinha muito trabalho
para fazer este mês - mas eu acredito que instalando de tarballs é uma habilidade que é necessário para qualquer utilizador de
Linux, e meu pensamento aqui era documentar o processo, inclusive resolução de instalações que saem errado. É algo com que
eu lutei em meus primeiros tempos de Linux, e eu gostaria de salvar outros de pelo menos um pouco daquela dor. : )

Assim. Nós vamos corajosamente em frente. Quando eu digo que falhou, exactamente o que eu vi? Bem, um "make" deveria
correr sem erros. Às vezes - frequentemente - você terá umas mensagens de aviso/advertências que não são a mesma coisa; as
suas bibliotecas podem ser ligeiramente diferentes, ou talvez seu compilador é um pouco mais rígido sobre declarações - mas
estes normalmente não são fatais. Os erros que interrumpem uma compilação sem a terminar - esses são os que nós temos que
corrigir. Portanto, aqui está como tudo aconteceu:
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$
O erro começa na linha que com "In file included...", e termina com (pelo menos a parte que queremos). "..qglobal.h: No such
file or directory". OK - está nos faltando um arquivo header. Eu dei uma olhada rápida pela árvore de fontes do "cuyo", só para
ter a certeza que o autor não se esqueceu de incluir um dos seus próprios arquivos (yeah, acontece) - não. Deve ser um dos
meus - quer dizer, o programa dele tem que estar procurando um arquivo que vem com uma biblioteca que eu preciso estar
usando no meu sistema para o programa dele compilar. Hmm. Qual? Seja qual for que contém "qglobal.h", claro.

No meu sistema, eu montei vários scripts para me ajudar com tarefas de instalação normalizadas. Um destes é o "pkgf" - ele
encontra qualquer arquivo que eu esteja procurando na distro inteira do Debian, e me diz em que pacote esse arquivo existe
(isto não é igual a "dpkg -S < file>" que faz isto só para pacotes instalados.) Se você usa Debian, você pode adquirir a mesma
funcionalidade carregando o actual "packages.gz" de <ftp://ftp.debian.org> e fazer "zgrep" por ele até encontrar o nome do

2
arquivo - ou, vá simplesmente a <http://www.debian.org/Packages> e use o utilitário de procura deles. O ponto é encontrar o
pacote que contém "qglobal.h" e instala-lo.

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

Bem, bem - parece que tenho vários pacotes por onde escolher. OK, "libqt3-dev" parece ser a coisa mais recente:

apt-get install libqt3-dev

A instalação foi bastante rápida, e... Eu apanhei o mesmo erro quando voltei a correr o "make". E você também o teria.
Portanto, não faça isso. A coisa a não esquecer aqui (e eu soube que eu tive o erro - eu fiz isto para marcar um ponto) é que
você já correu o "./configure": os valores antigos (quebrados) ainda estão no Makefile, como também em vários outros
arquivos, assim, em lugar de desperdiçar tempo e tentar descobrir onde eles possam estar:

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

Em outras palavras, eu simplesmente livrei-me de todo o directório do "cuyo" e o substituí com uma nova cópia da fonte. Esta
é em geral uma regra boa e simples: quando em dúvida, volte para as fontes originais. Acredite ou não, eu aprendi esse truque
de um mecânico de barcos que fez um trabalho extraordinariamente bom. O modo como o Kenny o disse foi "volta aquilo que
você sabe ser bom, então construa de lá. " Eu nunca vi o conselho dele sair errado; obviamente, clientes tendem a gritar quando
você lhes diz que você tem que jogar fora o pedaço de lixo de software que eles têm neste momento e substituir de cima
abaixo... mas depois de um tempo, a palavra se espalha: " Ei, o trabalho deste sujeito é bom. " Você pode perder alguns
trabalhos deste modo - eu sei que eu perco - mas, como Kenny, eu não quero deixar o meu nome associado a um pedaço de
lixo.

Eu sei, eu sei - eu estou falando sobre coisas que são mais gerais que um simples instalação de um tarball. A questão é, a
filosofia de como você faz coisas tem que vir em algum lado - e é melhor se você entender como você vai fazer as coisas de
facto antes de as realemte fazer, a metodologia global tanto quanto os pormenores do trabalho. OK, assim, voltando à pergunta
principal - trabalhou ou não???
ben@Baldur:/tmp/cuyo-1.03$ ./configure
<No errors>
ben@Baldur:/tmp/cuyo-1.03$ make
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$
Ta-daaa!!! Não deu erros - e quando eu entro no directório "cuyo-1.03/src", há um agradável executável chamado "cuyo"
poisado ali . Neste momento, se eu quisesse continuar a instalação (em vez de simplesmente testar o jogo para ver se gosto), eu
digitaria
make install
Isto leria o Makefile e executaria todos os comandos debaixo da opção "install" que instalaria provavelmenteo o[s]
executávei[s], as páginas do man[ual], e a documentação. Porém, eu teno tendência a brincar primeiro com o programa, e ver
se eu gosto dele - a maioria dos makefiles de tarball não incluem uma opção "uninstall" (o qual eu penso é uma vergonha; isso
faria os pacotes tarball quase tão fázeis de instalar e remover como , por exemplo, os RPMs ou DEBs.)

3
Para recapitular a completa instalação do tarball:

1) Confira se contém um directório ou somente (que rude!) ficheiros dispersos

2) Desemmpacotar para um directório debaixo de "/tmp" or "~/tmp"
3) Corra o "configure" se existir.
4) Corra o "make", ou "cc" se for um simples arquivo "file.c" ou "file.cc"
5) Corra o "make install" se o resultado é o que você quer.

É practicamente tudo. Note que eu não discuti segurança em lado nenhum aqui (você realmente confia no autor deste tarball ou
pacote? Você não está ligado como root enquanto trabalha com o binário, certo?), nem em muitos dos outros assuntos que
pertencem à administração do sistema; estes assuntos são muito importantes e altamente pertinentes, mas fora do âmbito deste
pequeno artigo. O sábio administrador de sistemas - e que, meu caro utilizador caseiro, é você; não há mais ninguém para a sua
máquina! - lerá muito, pensará profundamente, e considerará sabiamente.

Boa sorte, e que todas as suas dependências acabem sendo resolvidas. :)

Ben Okopnik

Ben Okopnik

Cyberjack-para-todo-o-serviço, o Ben navega pelo mundo no seu veleiro de 38', construindo redes e fazendo hacking em
hardware e software sempre que ca sem dinheiro para viajar. Ele tem trabalhado e brincando com computadores desde os Dias
Mais Antigos (álguem se lembra do Elf II?), e não está pronto para parar brevemente.

Copyright © 2002, Ben Okopnik.

Licença de cópia http://www.linuxgazette.com/copying.html
Publicado no Numero 74 da Gazeta do Linux, Janeiro 2002