Usando o i4l para criar instaladores de aplicativos para linux

gnumaru · 23 de Outubro de 2010, 17:23

Instalar aplicativos em sistemas GNU/Linux tem sido uma luta de longa data.
Antes de 1993, para ter um sistema funcional, era necessário compilar tudo, desde o kernel, passando pelas ferramentas GNU, até as aplicações desejadas.
Hoje em dia isso é passado, e a instalação de programas no linux se tornou algo até mesmo trivial. Tendo uma conexão com a internet, basta um simples comando, como "apt-get install <programa>" ou "yum install <programa>" para termos o aplicativo desejado. Se ele não estiver nos repositórios padrão da distro, provavelmente pode ser encontrado em algum outro repositório. Se nem isso for possível, sempre existe a opção de compilar por conta própria, que embora nos remeta a um passado onde essa era a única opção, agora só se torna necessário em casos extremos.

Contudo, ainda existe um caminho a galgar.

Usuários windows estão muito acostumados com o paradigma NNF (next, next, finish) quando se trata de gerenciar aplicações. Além disso, estão acostumados a baixar por sua própria conta o instalador do aplicativo, que consiste em um único arquivo executável que contém todo o necessário para rodar o aplicativo.

No mundo GNU/Linux, as coisas são diferentes.
   O usuário não precisa abrir o navegador e nem entrar em site algum para baixar o instalador.
   O "instalador" vem dividido em partes, ou seja, um pacote principal e suas dependências.
   O comando de instalar o programa é o mesmo de baixar.

Essas diferenças, além de outras, como o fato dos arquivos de aplicativo ficarem espalhados pelo sistema afora, confunde usuários vindos do Windows ou do Mac. Esta diferença de paradigma não é um fator crucial para determinar o uso ou não de sistemas GNU/Linux, mas não deve ser desconsiderada.

Além disso, temos um problema clássico, a instalação de aplicativos em máquinas offline, que abordei em uma outra dica:

http://www.vivaolinux.com.br/dica/Instalacao-de-programas-em-maquinas-offline

No intuito de criar um sistema de instalação de aplicativos onde todos os pacotes se encontrassem em um único arquivo, e onde fosse possível instalá-los em qualquer máquina offline, mesmo que esta jamais tivesse atualizado sua lista de pacotes do repositório, criei um projeto no sourceforge chamado i4l (installers for linux)

https://sourceforge.net/projects/i4l/

O i4l não é uma nova forma de gerenciador de pacotes. Ele é uma espécie de "wrapper" ao redor do apt. Um pacote criado com o i4l contém todos os pacotes deb necessários para instalar determinada aplicação em um sistema qualquer, mesmo em máquinas offline, onde a lista de pacotes do repositório nunca foi baixada.

O código é feito integralmente em shell script e a interface com o usuário é feita com o zenity, ou o xmessage caso o zenity não esteja disponível. Por enquanto, ele é compatível com as versões i386 dos seguintes sistemas: Ubuntu 10.10, 10.04, 9.10, 9.04, 8.04 e Debian lenny.

É possível criar instaladores para qualquer aplicação disponível nos repositórios da distro. É possível também criar instaladores para uma distro alvo diferente daquela que você está usando para criar o instalador.

A seguir, darei as instruções de como utilizar o i4l para criar instaladores.

Primeiro, baixe o preparador do sistema (i4l-system-preparer.sh), disponível no sourceforge

https://sourceforge.net/projects/i4l/files/packaging%20kit/i4l-system-preparer-0.1b5.run/download

Em seguida, execute o arquivo e siga as instruções da tela.
Ao fim do processo, o seu sistema estára pronto para criar instaladores.

Se você é do tipo cuidadoso, que não sai executando todo arquivo que baixa por aí, abra o arquivo no gedit ou outro editor de texto qualquer. Trata-se de um arquivo compactado com o bzip2 com um cabeçalho de shell-script, encarregado de extrair e executar o conteúdo do arquivo. Este arquivo compactado auto-extraível, assim como os instaladores do i4l, são todos gerados usando o makeself, disponível na seguinte página:

http://megastep.org/makeself/

Se quiser somente extrair o conteúdo do pacote para ver o que tem dentro, execute-o no terminal com os parâmetros "--keep e --noexec". Isto criará uma pasta no diretório atual com todo o conteúdo do pacote. Isto também vale para os instaladores gerados com o i4l.

Após executado o preparador do sistema, se quiser, execute o comando i4l-set-target-system.sh para escolher o sistema alvo para o qual deseja criar instaladores.

Quando quiser criar um instalador, basta executar o comando:

# i4l-installer-creator.sh <nome-do-programa>

para gerar um instalador, que será colocado no seu diretório home.
Note que <nome-do-programa> é o nome de qualquer pacote disponível nos repositórios de sua distro.
Exemplos:

# i4l-installer-creator.sh gimp
# i4l-installer-creator.sh chromium-browser
# i4l-installer-creator.sh broffice.org

Conclusão

Meu objetivo maior, ao criar o i4l, foi desenvolver uma maneira fácil de instalar programas em máquinas offline. Além disso, ele se mostra útil para fazer backup de aplicativos, para aqueles que tem conexão lenta e não querem baixar um programa mais do que uma única vez.
Existe também a possibilidade de usar o aptoncd para fazer backup de pacotes deb, contudo quando se trata de fazer backup de um único aplicativo, e não de uma coleção deles, o uso do i4l se mostra mais simples. De fato, inicialmente o i4l foi inspirado pelo aptoncd. Agradeço muito tanto àqueles que criaram o aptoncd, e aos criadores do makeself, que uso para criar os pacotes auto-extraíveis.

O i4l ainda está em fase inicial, mas já é capaz de fazer aquilo que ele propõe: Criar instaladores de aplicativos para Linux.

Ficaria extremamente grato de receber críticas e sugestões daqueles que o utilizarem.
Pretendo, futuramente, aumentar o escopo do i4l para abranger sistemas baseados em pacotes rpm.

No mesmo projeto do sourceforge, hospedei uma série de instaladores de aplicativos, para Ubuntu 10.10 e 10.04. Quem se sentir a vontade pode testa-los e me dizer o que achou.
Mandem as críticas e sugestões para.

gnumaru<arroba>users<ponto>sourceforge<ponto>net

Troquem o <arroba> por "@" e o <ponto> por ".". Procedimento padrão anti-spam.

Ficarei feliz se puder nortear o desenvolvimento do i4l com base nas sugestões dos usuários.

vampire_thunder · 23 de Outubro de 2010, 18:28

Parece ser sensacional!
Vou testar bastante isso.

Holmes · 23 de Outubro de 2010, 18:55

Citação de: vampire_thunder online 23 de Outubro de 2010, 18:28
Parece ser sensacional!
Vou testar bastante isso.

gnumaru

Vou testar aqui...

vlw fwi, Viva

vampire_thunder · 26 de Outubro de 2010, 12:17

Sacanagem, nem me liguei, só funciona no 32 bits

gnumaru · 26 de Outubro de 2010, 13:28

Não tema, caríssimo usuário!
Usuários de sistemas de 64 bits podem utilizar aplicativos de 32 bits!

Como eu mesmo havia dito, "Ficarei feliz se puder nortear o desenvolvimento do i4l com base nas sugestões dos usuários."

Saiba que o suporte à arquitetura de 64 bits, a AMD64 (as vezes chamada de X64 ou X86-64), é um item crucial na minha lista de tarefas.

Até agora eu desenvolvi o i4l focado na arquitetura de 32 bits pelo simples e banal fato de que a única máquina que eu possuo, que eu adquiri em 2005, suporta somente instruções de 32 bits.

Mas adianto que muito em breve teremos o suporte à arquitetura de 64 bits.
Para fazer isso, a única coisa que me falta é baixar as versões 64bit dos sistemas alvo suportados pelo i4l, instala-los e extrair o arquivo /var/lib/dpkg/status logo após a instalação.

Por enquanto, os usuários de sistemas de 64 bits podem sim instalar aplicativos de 32 bits criados com o i4l. Basta ter instalado as bibliotecas de compatilibade com executáveis de 32 bits.
No Ubuntu, o pacote para estas bibliotecas é o "ia32-libs", disponível desde o ubuntu 6.06 (talvez até antes).
Se não me engano, ele já vem instalado por padrão nas versões 64bit do ubuntu.

Contudo, por não ter ainda uma máquina de 64bit para testes, preferi esperar até poder implementar essa função ao invés de instruir um usuário 64bit a instalar aplicações 32bit.

vampire_thunder · 26 de Outubro de 2010, 21:07

Citação de: gnumaru online 26 de Outubro de 2010, 13:28
Não tema, caríssimo usuário!
Usuários de sistemas de 64 bits podem utilizar aplicativos de 32 bits!

Como eu mesmo havia dito, "Ficarei feliz se puder nortear o desenvolvimento do i4l com base nas sugestões dos usuários."

Saiba que o suporte à arquitetura de 64 bits, a AMD64 (as vezes chamada de X64 ou X86-64), é um item crucial na minha lista de tarefas.

Até agora eu desenvolvi o i4l focado na arquitetura de 32 bits pelo simples e banal fato de que a única máquina que eu possuo, que eu adquiri em 2005, suporta somente instruções de 32 bits.

Mas adianto que muito em breve teremos o suporte à arquitetura de 64 bits.
Para fazer isso, a única coisa que me falta é baixar as versões 64bit dos sistemas alvo suportados pelo i4l, instala-los e extrair o arquivo /var/lib/dpkg/status logo após a instalação.

Por enquanto, os usuários de sistemas de 64 bits podem sim instalar aplicativos de 32 bits criados com o i4l. Basta ter instalado as bibliotecas de compatilibade com executáveis de 32 bits.
No Ubuntu, o pacote para estas bibliotecas é o "ia32-libs", disponível desde o ubuntu 6.06 (talvez até antes).
Se não me engano, ele já vem instalado por padrão nas versões 64bit do ubuntu.

Contudo, por não ter ainda uma máquina de 64bit para testes, preferi esperar até poder implementar essa função ao invés de instruir um usuário 64bit a instalar aplicações 32bit.

Muito obrigado pela resposta. Esse é o diferencial do SL: você pode conversar com o criador e colaborar com o projeto.

Geralmente os programas 32 bits funcionam no 64, sim. Principalmente se forem scripts. Aí é que funcionam mesmo.
Para montar o Lineduc eu fiz uma jogada que muitas vezes dava certo. No site oficial só tinha o pacote .deb i386. Eu baixava, descompactava, mudava o control de "i386" para "all" e recompactava novamente. Depois instalava para ver e geralmente funcionava. Um exemplo é o MobileMediaConverter.
Ou seja, nem os desenvolvedores às vezes sabem que seu software roda em ambas arquiteturas e criam um pacote i386 desnecessariamente, quando já poderia criar "all".

Vou fazer uns testes com seu script no Lineduc 64, que já tem as libs 32 instaladas porque o Wine só funciona com elas, infelizmente. Apesar da tecnologia já existir há anos, ainda não é possível ter um sistema totalmente 64 bits.

Kriptolix · 26 de Outubro de 2010, 21:20

sinto um cheiro de mudança no ar... a quantidade de vezes que ja me deparei com o problema de instalar algo ofline (e suas milhares de dependencias) ultrapassa minha contagem de memoria. parabens pela ideia e pelo desenvolvimento, vou testar assim que possivel.

uma pergunta/sugestao: é possivel automatizar uma instalaçao em lote de varios aplicativos? aptoncd eu sei que faz algo nessa linha, mas a questao esta mais pra pegar varios aplicativos de varios amigos e poder instalar todos de uma vez.

gnumaru · 27 de Outubro de 2010, 10:27

Citação de: kriador online 26 de Outubro de 2010, 21:20
é possivel automatizar uma instalaçao em lote de varios aplicativos? aptoncd eu sei que faz algo nessa linha, mas a questao esta mais pra pegar varios aplicativos de varios amigos e poder instalar todos de uma vez.

Eu imagino que sim.
Por padrão, os instaladores criados com o i4l são bem "tagarelas", pedindo intervenção do usuário em vários instantes e carecendo de interface gráfica para serem rodados, já que a interface com o usuário é feita com o zenity ou xmessage.
Eu poderia alterar o script de instalação para admitir algum parâmetro do tipo "--silent" ou "-s". Desta forma, um usuário poderia fazer algo do tipo:

# cd /home/usuario/diretorioCheioDeInstaladores
# for INSTALLER in *.run; do ./$INSTALLER --silent; done

Ou seja, um loop em todos os arquivos .run do diretório atual, instalando um a um silenciosamente.
O problema disso é que pode acontecer de algum dos programas a serem instalados terem pacotes que conflitam com algum outro pacote já instalado no sistema. Em um caso desses, o melhor é perguntar ao usuário o que fazer. Mas se quisermos um comportamento totalmente silencioso, é necessário ter um procedimento padrão. Na minha opinião, o melhor sería não instalar aquele programa específico.