Esse artigo tem como finalidade mostrar como é fácil criar o seu próprio pacote tgz, desta forma você pode manter o seu sistema bem mais organizado e controlando os pacotes existentes nele, podendo removê-los ou reinstalá-los quando precisar.
O processo de criação é bem simples, você pode ainda executar
isso como usuário comum. Os programas normalmente são copiados
para sua pasta de destino seguindo a variável DESTDIR ou destdir,
caso o programa que você quer instalar não reconheça essa variável,
tente usar a PREFIX ou prefix. Coloco em caixa alta ou baixa pois
o script configure pode conter em ambos os formatos, mas
usar DESTDIR ou destdir funciona da mesma forma.
Eu só uso o DESTDIR, pois ele gera o pacote da forma correta, só
use o PREFIX caso o DESTDIR não funcione, aí você irá precisar
mudar algumas coisas que explico depois.
# mkdir /tmp/programa-versão
# make install DESTDIR=/tmp/programa-versão
Caso você tenha precisado usar o PREFIX não se desespere, é bem
fácil resolver. O make irá copiar todo o conteúdo para a
pasta usr, incluindo etc, mova o etc para o
seu lugar correto:
# mkdir /tmp/programa-versão
# mkdir /tmp/programa-versão/usr
# make install PREFIX=/tmp/programa-versão/usr
# cd /tmp/programa-versão
# mv usr/etc .
Pronto, não foi simples? Agora os arquivos estão no lugar certo,
você pode seguir o resto do artigo.
Agora entre na pasta /tmp/programa-versão e veja que foram
criadas todas as pastas: usr, etc, opt,
lib ou qualquer outra que o programa precisar.
Precisamos criar agora a pasta de documentação, existem vários
arquivos importantes que devem ser mantidos junto ao programa,
como a licença GPL, README etc, alguns programas possuem a pasta
doc onde normalmente vem arquivos extras, como ícones e
arquivos ps ou pdf e documentação extra. Dê uma olhada nisso
também e copie tudo para a pasta de destino.
Essa parte é opcional, mas é muito boa de ser feita. Alguns
programas vem com nome como programa-bin, você não pode
renomeá-lo, mas pode criar um link com o nome correto. Comprima
as man pages e se quiser a documentação também. Como cada programa
cria uma man page diferente, você precisa ver quais foram criadas,
pode ter uma pasta man1, man2, man3, etc... e faça isso em todos
os arquivos que encontrar.
# cd /tmp/programa-versão/usr/bin
# ln -s programa-bin programa
# cd /tmp/programa-versão/usr/man/man1
# gzip -9 programa.1
Agora volte para a raíz do seu novo programa e crie uma pasta
chamada install. Lá você pode criar dois arquivos, o
slack-desc e doinst.sh.
O primeiro é a descrição que vai aparecer no pkgtool quando
você for instalar o mesmo e o segundo é um script que é executado
após a instalação, você pode adicionar aí comandos para copiar ou
apagar algo, bom isso é mais avançado, deixaremos para outro
artigo.
Vamos então criar a descrição, segue o arquivo slack-desc do
próprio pkgtools:
# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package
# description. Line up the first '|' above the ':' following the base
# package name, and the '|' on the right side marks the last
# column you can put a character in. You must make exactly
# 11 lines for the formatting to be correct. It's also customary to
# leave one space after the ':'.
|-----handy-ruler------------------------------------------------------|
pkgtools: pkgtools (The Slackware package maintenance system)
pkgtools:
pkgtools: This package contains utilities for handling Slackware packages.
pkgtools: Included are the command line utilities 'installpkg', 'removepkg',
pkgtools: 'makepkg', 'explodepkg', and 'upgradepkg' that install, remove,
pkgtools: build, examine, and upgrade software packages. Also included are
pkgtools: 'pkgtool', a menu based program for installing packages, removing
pkgtools: packages, or viewing the packages that are installed on the system,
pkgtools: documentation (man pages), and a few other system admin scripts.
pkgtools:
pkgtools:
Note que existe uma régua que está alinhada com os dois pontos
após o nome do programa, coloque o nome do programa e após isso
alinhe-o novamente caso o nome seja maior ou menor que
pkgtools, faça isso apagando os espaços em branco antes da
régua e não deixe o nome ser muito grande, deixe com no máximo 8
caracteres. Bom, mas por que essa palhaçada de régua? Você pergunta,
é que a descrição não pode passar da margem direita da régua, senão
ela não será aceita pelo pkgtools!
O limite é de 70 caracteres no texto e a régua facilita para você
não ficar contando letra por letra =). É bom manter um espaço
entre os dois pontos e o texto, para melhor visualização e o número
de linha deve ser mantido em 11 linhas, nem mais nem menos.
Outra coisa é que o arquivo precisa estar em UTF-8, todos os
editores de textos salvam nesse formato, gedit, kedit,
etc, é só mudar na hora de salvar.
Uma coisa que aprendi com o meu amigo Blood_Brother foi a
retirar textos desnecessários dos binários, isso é completamente
opcional, mas pode diminuir bastante o tamanho dos binários.
Retirando símbolos de debug
Por: Blood_Brother)
O programa usado para retirar os símbolos de debug é o strip,
no entanto vou passar uma receita de bolo de como usá-lo diretamente
em seu programa compilado.
Feito isto o tamanho do seu pacote gerado será bem reduzido.
(fim do artigo do Blood_Brother)
-----------------------------------------
Depois de tudo criado e revisado é hora de chamar o nosso amigo
root, isso mesmo, agora vai ser efetuada a parte que só o
root pode fazer, que é mudar as permissões dos arquivos, pois
senão for feito isso o seu programa será instalado com o seu
login, o que não é nem um pouco legal, imagina você tendo acesso
de escrita na pasta /usr e sem querer apaga toda a pasta?
Isso seria péssimo, lembre-se, você foi avisado. O nome do pacote
é muito importante também, o Slackware segue o seguinte padrão:
programa-versão-arch-1.tgz
Onde:
programa - é o nome do programa, caso ele tenha um nome
composto separe-os por hífen também. Um exemplo é o
mozilla-1.6-i486-1.tgz e
mozilla-plugins-1.6-i486-noarch.tgz.
versão - é a versão do programa, o que inclui o pre,
alpha, rc, beta etc... caso você esteja criando um pacote
de um programa não finalizado. Um exemplo é o
mplayer-1.0pre3-i486-1.tgz.
arch - aqui é onde você irá colocar a máquina pra
qual foi compilada, lembre de não colocar i486 se você não
compilou para 486! A opção noarch é para programas que não
precisam de compatibilidade com processador, o que inclui
scripts em geral. Um bom exemplo é o
slackpkg-1.00-noarch-2.tgz.
1 - aqui você coloca o build, construção em Português,
caso você tenha precisado recompilar o mesmo programa ou
alterar algo no seu conteúdo, como um link errado. Isso é
bom porque você vai poder atualizar o pacote e manter um
controle das compilações que fez.
tgz - obviamente é a extensão, não ponha .tar.gz,
apesar de ser a mesma coisa para qualquer programa de
descompressão, não é a terminação correta.
# cd /tmp/programa-versão
# makepkg programa-versão-arch-1.tgz
Pronto, agora você terá um arquivo programa-versão-arch-1.tgz
na raíz da instalação, pronto para ser instalado.
Execute o pkgtool e escolha Current que você verá a
descrição do seu novo programa, caso tenha seguido tudo corretamente,
selecione install ou upgrade conforme a necessidade.
Copie o pacote para uma pasta, você pode precisar dele mais tarde.
[3] Comentário enviado por lordello em 30/01/2004 - 12:37h
Está faltando so uma coisa, após executar o comando makepkg ele irá fazer duas perguntas, uma sobre mudar as permições e outra sobre criar o script doinst.sh, normalmente ele usa esse script para recriar os links dos programas. É só dar enter nas duas perguntas, pois o padrão é sim para ambos...
Falow!
[4] Comentário enviado por jllucca em 20/03/2004 - 19:33h
Lordello,
O artigo tá excelente ! So queria acrescentar que é importante passar o caminho absoluto para a variavel DESTDIR. Já que em alguns casos pode haver reclamação por parte do make se tentarmos usar um caminho relativo.
Caminho relativo seria no caso dos exemplos, estar no diretorio /tmp e passar para DESTDIR somente "programa-versão".
[6] Comentário enviado por lordello em 04/07/2004 - 22:49h
Eu é que não entendi! Escrevi um artigo sobre como criar pacotes já compilados para ser instalado no Slackware. O código fonte dos programas são distribuídos nos formatos .tar.gz e .tar.bz2. O segundo (bz2) comprime mais e é mais usado hoje. Agora claro, o tar.gz é o mesmo do que o .tgz, mas e aí? O que você não entendeu?
[8] Comentário enviado por hdoria em 04/02/2005 - 13:59h
Vamos supor que exista uma lib faltando para o programa funcionar. Tem como na hora de criar o pacote, adcionar esta lib ao pacote? Assim, quando alguem instalar esse pacote criado, ele nao precisara baixar a lib.
[9] Comentário enviado por lordello em 04/02/2005 - 15:09h
Sim é possível, mas isso é TOTALMENTE ERRADO. Imagine que um dia o individuo instale a tal biblioteca na mão, sem saber que ela foi fornecida junto com algum programa??? Você acha que depois de alguns dias ele vai lembrar que existe essa biblioteca dentro do pacote que você criou??? Afinal de contas é por isso que é importante criar pacotes, porque o sistema vai registrar no banco de dados que o pacote está instalado, no futuro a pessoa pode checar o que está ou não instalado, sem maiores problemas.
Os pacotes devem conter apenas o programa em questão, caso queira distribuir um programa junto com as bibliotecas extras, crie um arquivo zip/rar/ace com todos os pacotes dentro.
Falou ae!
[10] Comentário enviado por jllucca em 04/02/2005 - 22:48h
Opa, lordello!
Eu gostei da pergunta do n0z3y, mas acho que ele não soube como fazer. Tem como fazer o pacote ser "dependente" de outros pacotes? Se tem, como fazer? Tipo os rpms, onde as vezes precisamos dos rpms "tais" pros pacotes "taus"(hehehe).
[11] Comentário enviado por lordello em 05/02/2005 - 01:11h
Sim, os gerenciadores de pacotes swaret e slapt-get usam um método alternativo para checar dependências, já que o Slackware não fornece nativamente suporte a dependências. Como não é oficial, é bom ter em mente que você deve testar isso com a ferramenta correta.
Dentro da pasta "install" do pacote você pode criar três arquivos, um vai informar ao instalador os pacotes necessários (slack-required), outro vai informar os pacotes conflitantes (slack-conflicts) e o último vai sugerir pacotes com funcionalidades extras (slack-suggests).
Vamos supor que o programaX precisa das bibliotecas libA-1.2 libB-3.5 libC-2.1 e se você instalar a "libD" vai habilitar um suporte extra, mas ele (programaX) não pode ser instalado junto com o programaY de jeito algum, pois eles não funcionam juntos... ficaria algo assim:
slack-required:
>=libA-1.2
>=libB-3.5
>=libC-2.1
Aqui podem ser usados simbolos típicos que, quem programa bash/perl/python, já deve estar acostumado, símbolos tipo maior > menor < igual =. Claro, algumas combinações não são lógicas, o normal é usar ">=" (maior ou igual).
slack-conflicts:
programaY
slack-suggests:
libD
Tipo, se o libB precisasse ser uma versão exata você colocaria assim:
=libB-3.5
Então você pode controlar bem quais biliotecas serão instaladas. Ás vezes você precisa fornecer informações mais específicas, como arch e build, isso torna a instalação específica, pois para o instalador não vai bastar ser a biblioteca com nome correto, essa vai ser uma versão específica, por exemplo:
>=libB-3.5-i486-1lord
Ou seja, não bata ser a biblioteca libB-3.5 ou maior, ela tem que ser compilada por mim (1lord, 2lord, 3lord etc...) e tem que ser compilada para i486. Mas muita atenção, para compilar o pacote pra i486 é preciso usar o comando indicado no artigo, muitas pessoas esquecem e só digitam "./configure", fazendo isso o programa é compilado específicamente para o processador da máquina atual, ou seja, se for um athlon o pacote vai ser para athlon etc... Isso é um erro, pois o pacote não se torna compatível com todas as máquinas.
Como disse, isso não é uma regra e não sei o que está atualmente funcionando com o slapt-get, o swaret usa um servidor próprio que tenta adivinhar as dependências apenas pelo banco de dados deles, não levando em conta esses arquivos. Claro, eu não sei a posição atual do desenvolvimento desses programas, pode ser que hoje (05/02/2005) haja uma solução mais universal. A melhor opção no meu ver é usar o próprio arquivo "slack-desc" para gerar dependências. No final do arquivo pode ser incluída qualquer quantidade de texto extra, isso abre uma brecha para que seja adiconado o controle de dependência nele da mesma forma que descrevi acima, mas com alguma simbologia que substitua os três arquivos, algo como "!>=" para o conflicts e "?>=" para o sugest. Mas isso é minha opinião, não sei se vai ser assim, não sou vidente nem estou em contato com o desenvolvimento dessas ferramentas.
Esse assunto é muito legal, mas claro, isso depende muito da ferramenta usada e de como o pacote é feito.
Falou ae!
Bom, para você tomar como exemplo, ficou bem diferente do que era proposto incialmente, talvez enm funcione, talvez sim. É bom dar uma olhada em vários pacotes e na documentação do slapt-get para saber mais detalhes de como está sendo feito esse controle.
Falou ae!
[14] Comentário enviado por lordello em 19/11/2005 - 20:12h
Isso nunca aconteceu, se o arquivo slack-desc estiver correto, ele será exibido de forma correta.
É só seguir a regra de número de linhas e usar codificação UTF-8.
Tente não usar acêntos, ja que o universal é usar inglês mesmo. Se o pacote for em português, tente evitar acêntos a todo custo.
Até mais.
[16] Comentário enviado por lordello em 05/02/2006 - 01:17h
É possível criar pacotes para qualquer programa. Todos os programas bem feitos possuem excelentes arquivos Makefile, que é o responsável por toda a compilação e instalação. Com alguns programas é necessário um trabalho maior, às vezes manual, mas é sempre possível empacotar qualquer programa.
[17] Comentário enviado por jpfaria em 21/08/2006 - 23:15h
Opa,
tentei criar o pacote do PHP com mais suporte do que vem nativo no slackware. Simplesmente o comando:
make install PREFIX=/tmp/pkg/usr
nada é criado em /tmp/pkg..
testei tb em outros programas maiores e todos ignoram o PREFIX e instalam normalmente no sistema.
Alguem sabe o que esta acontecendo ?
abs
[18] Comentário enviado por lordello em 24/08/2006 - 22:32h
Caro amigo jpfaria, existe este trecho no artigo:
(...)Eu só uso o DESTDIR, pois ele gera o pacote da forma correta, só use o PREFIX caso o DESTDIR não funcione, aí você irá precisar mudar algumas coisas que explico depois.(...)
Ou seja, use o DESTDIR sempre! A opção PREFIX é apenas no caso do DESTDIR não funcionar.
Este artigo é datado de 29/01/2004, ou seja, desde aquela época muita coisa pode ter mudado.
Na época eu tinha visto programas não aceitarem a variável DESTDIR, mas todos aceitavam a PREFIX, porque é ela que o arquivo Makefile usa para endereçar a cópia dos arquivos. Se por algum motivo parou de funcionar e a DESTDIR não funciona no programa em questão, então o jeito é instalar na mão, ou usando o CheckInstall. http://asic-linux.com.mx/~izto/checkinstall/
[22] Comentário enviado por lordello em 15/02/2017 - 09:24h
[21] Comentário enviado por lindbergluiz em 15/02/2017 - 00:41h
Este procedimento também serve para pacotes encontrados no formato .zip?
Por exemplo, quero instalar a versão mais atual do MuseScore (2.0.3) mas está apenas disponível o código-fonte no pacote .zip.
Pelo repositório do SlackBuilds, a única versão é 1.3.
Como devo proceder para criar o pacote de instalação da versão 2.0.3?
Caro Luiz, esse tutorial serve para qualquer aplicativo com código fonte que use o sistema MAKEFILE, ele pode estar compactado em qualquer formato. Extraia o pacote em alguma pasta e verifique seu código.
Lembre-se que esse tutorial é bem antigo, por tanto algumas adaptações podem ser necessárias para fazer a instalação corretamente.
Abraço.
[24] Comentário enviado por lindbergluiz em 16/02/2017 - 23:37h
lordello,
não obtive sucesso pelo simples fato de não existir o "configure" em nenhuma pasta do pacote. Como é possível criar o pacote, a partir do código-fonte, sem o configure?
[25] Comentário enviado por lindbergluiz em 16/02/2017 - 23:37h
lordello,
não obtive sucesso pelo simples fato de não existir o "configure" em nenhuma pasta do pacote. Como é possível criar o pacote, a partir do código-fonte, sem o configure?
[26] Comentário enviado por lordello em 17/02/2017 - 00:05h
O arquivo que você baixou possui um sistema de compilação do Makefile apenas, todas as instruções estão descritas no arquivo README.md...
compilando: make release
instalando: make install
Segundo o próprio README.md o programa pode ser executado da pasta, sem instalar ou criar pacote, o comando seria esse:
# ./build.release/mscore/mscore
O Makefile desse código fonte usa a variável PREFIX como pasta de instalação, é preciso usar na hora de direcionar a instalação, como descrito no artigo.
"make install PREFIX=/PASTA/DE/INSTALACAO/TEMPORARIA"
Qualquer dúvida sobre a instalação ou configuração de bibliotecas, por favor leia o README.md, existem algumas bibliotecas necessárias para o programa rodar.
Abraço.