[1] Comentário enviado por JuNiOx em 30/01/2004 - 00:45h

Ae lordello!

muito legal seu artigo!

[]'s

0 0

[2] Comentário enviado por hugh em 30/01/2004 - 09:17h

E ae tio Lodello!
parabéns pelos artigos
ta virando um especialista em Slackware!!! :D
valews
[]'s

Victor

0 0

[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!

0 0

[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".

0 0

[5] Comentário enviado por Ilovelinux2004 em 04/07/2004 - 18:38h

olá, eu naum entendi muito bem, aki mesmo no site, eu ouvi dizer que os pacotes.tar.gz e os pacotes.tgz são as mesmas coisas...

conexaolinux2004@ig.com.br

0 0

[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?

0 0

[7] Comentário enviado por Herr_Filip em 24/01/2005 - 17:49h

muito bom artigo
sempre tive interesse em aprender, artigo muito bem escrito!

parabens!
Felipe

0 0

[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.

0 0

[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!

0 0

[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).

[]'s

0 0

[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.

# ./configure --prefix=/usr --sysconfdir=/etc --build=i486-slackware-linux --host=i486-slackware-linux --target=i486-slackware-linux

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!

0 0

[12] Comentário enviado por lordello em 05/02/2005 - 01:16h

Acabei de ver um arquivo "slack-required" do LinuxPackages e ele se parece com isso:

# cat slack-required
audiofile >= 0.2.6
esound >= 0.2.34
gconf >= 2.6.1
glib2 >= 2.4.2
gnome-vfs >= 2.6.1.1
gnutls >= 1.0.13
libbonobo >= 2.6.2
libgcrypt >= 1.2.0
libgnome >= 2.6.1.1
libgpg-error >= 0.7
libsoup >= 2.1.11
libxml2 >= 2.6.9
openssl >= 0.9.7d
orbit2 >= 2.10.2

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!

0 0

[13] Comentário enviado por casterman em 19/11/2005 - 01:26h

otimo artigo, vc sabe, ou ja aconteceucom vc do pkgtool apresentar falha na descrição do pacote mesmo a descrição estando os conformes?

0 0

[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.

0 0

[15] Comentário enviado por nidiascampos em 04/02/2006 - 13:21h

Será que é possivel cria um pacote para um programa tipo o eclipse?

0 0

[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.

0 0

[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

0 0

[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/

0 0

[19] Comentário enviado por dark_slack em 16/05/2007 - 23:01h

poderiam usar o makepkg -l y -c n pacote.tgz

0 0

[20] Comentário enviado por blip em 02/08/2009 - 22:18h

Muito bom o artigo! Quando voce vai postar o artigo que explica a criacao de scripts para os pacotes .tgz? quero ler esse artigo tambem!

0 0

[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?

0 0

[22] Comentário enviado por lordello em 15/02/2017 - 09:24h



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.

0 0

[23] Comentário enviado por lindbergluiz em 16/02/2017 - 11:04h

ok. Valeu!

0 0

[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?

0 0

[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?

confira o pacote do MuseScore no link:

https://ftp.osuosl.org/pub/musescore/releases/MuseScore-2.0.3/MuseScore-2.0.3.zip

0 0

[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.

0 0