Empacotar é coisa do século passado – acordo de cooperação tecnológica

Caixas velhas

Em seu blog, Ian Murdock, o fundador do Debian nos diz em ‘Como gerenciamento de pacotes mudou tudo‘ que:

Qual é o maior avanço que o Linux trouxe para a indústria ? Essa é uma pergunta interessante, e uma que na minha opinião tem uma resposta simples: Gerenciamento de pacote ou, mais especificamente, a capacidade de instalar e atualizar software através da rede de uma forma transparente, integrada e elegante, juntamente com o modelo distribuído de pacotes. (adaptado)

De fato, é um diferencial ímpar. Mas esta tecnologia do mundo GNU Linux está presa ao século passado. Os programas já compilados que instalamos nas nossas distribuições favoritas são produzidos em um processo artesanal que me remete as antigas linhas de montagem em que cada produto precisava ser manualmente embalado.

Divido aqui a comunidade de software livre em dois grandes tipos: aquela que desenvolve, que está engajada diretamente na produção de software, na programação dele. São projetos como OpenOffice, Gnome, Apache etc. Do outro lado, temos também as comunidades que distribuem esses softwares, que fazem as distribuições como Debian, Ubuntu, Fedora, ArchLinux etc. São grupos bem distintos com culturas bem distintas e integrados pela prática rococó do empacotamento.

Para efeito de conversa, pensemos no Apache, exemplo favorito de Sergio Amadeu. Quando o projeto Apache lança uma nova versão de seu software, ele lança apenas o código fonte. Cada usuário GNU Linux, para utilizá-lo, tem que baixar o código-fonte e prepará-lo para compilar. Tal tarefa não é uma das mais fáceis e exige tomada de decisão baseada em quesitos técnicos. Cada dependência, cada pedacinho que compõe o programa teria que ser separadamente baixado, compilado e configurado manualmente. Para ferramentas grandes como Gnome e KDE isso chega a levar dias. Por isso vou um pouco além de Murdock: eu diria que o GNU Linux seria insalubre se não fossem os sistemas de gerenciamento de pacotes. Tais sistemas permitem a mágica do único comando ou com um punhado de cliques, o Apache seja instalado já previamente compilado e pré-configurado para o uso mais comum.

Mas… como o pacote do Apache ou de qualquer outro software são gerados ? Eis o processo que me dá arrepios: assim que uma nova versão do software é lançada, um voluntário de cada distribuição GNU Linux existente tem que manualmente fazer o download da nova versão do programa, compilá-la, configurá-la e por tudo isso em um pacote, que por si só, o empacotamento não é um processo simples e como a compilação, exige um engajamento em questões técnicas profundas. De fato, é uma otimização. Uma pessoa faz o trabalho sujo uma vez para que as outras milhares possam queimar essas etapas demoradas e chatas.

– Oras Kurt, mas se é tão bom, do que estas reclamando ?

Homer Simpson

Bem, não posso dizer pelos outros, mas me sinto muito estúpido quando sou obrigado a fazer algo que uma máquina faria muito mais rápido e eficientemente do que eu. Se toda a internet funciona com máquinas independentes, sendo a intervenção humana resumida a alguns Homer Simpsons olhando LEDs piscarem, por que cada singelo software tem que ser manualmente baixado, compilado, configurado e empacotado ? É uma perda de material humano e de tempo.

De fato, a força do Software Livre está em sua construção colaborativa. Mas precisamos depositar força de trabalho naquilo que realmente demanda por um cérebro orgânico. Por que não criamos scripts e softwares que automaticamente criem pacotes para cada distribuição ? Por que precisamos depender de um voluntário para que tenhamos em nossa distribuição favorita um software ? Tal processo ineficiente gera distorções: algumas distribuições tem um pacote e outras não, algumas tem versões mas atuais outras com versões antiquérrimas. Se todos usamos GNU Linux, por que manter em um cenário tão desigual em termos de disponibilidade de software ?

Em vez de cada distribuição criar a cada lançamento de softwares um pacote para ele, basta cada distribuição criar uma única vez um script para empacotar o Apache e a cada nova versão deste software, o script detecta, baixa, compila, configura e põe no repositório devido (por exemplo, os testing ou development).

– Eu já pensei nisso, mas é algo difícil de se fazer…

É difícil porque cada comunidade de desenvolvimento adota padrões diferentes. Tal diversidade atrapalha a construção destes scripts e intrisicamente seu funcionamento. O que venho aqui neste artigo propor de novo é um Acordo de Cooperação Tecnológica (ACT). Se conseguirmos padronizar o modus operandi das comunidades que desenvolvem software livre e das que distribuem, esses scripts funcionariam com tranquilidade. Mas, jamais para criar um padrão único para todas as distribuições e sim acordos de duas partes envolvidas: uma distro e um software combinam um padrão para que o empacotamento possa ser realizado. É a criação de um acordo, uma promessa de se deter a um padrão e não criar um padrão único. Exemplificando: é combinar qual vai ser o uniforme de um colégio e não que todos os colégios do mundo tenham o mesmo uniforme.

Nesse acordo, os projetos de softwares livres que possuem comunidade sólidas, como os que eu mencionei ao longo deste artigo, entrariam em acordo de cooperação com os responsáveis das distribuições que os utiliza ou os distribuem automaticamente instalados (como é o caso do Gnome para Ubuntu) para estabelecer algumas regras, algumas guidelines para o lançamento de novas versões. Onde fica que o arquivo XPTO, como que é a estrutura de XYZ, onde se armazenará o metadata da descrição do programa etc… de forma que:

a) A comunidade que desenvolve o software se compromete a seguir certos padrões no lançamento de seu código fonte, estabelecidos em consenso interno e com as comunidades das distribuições.

b) Cada distribuição assinante do acordo se compromete em desenvolver e manter scripts que façam o empacotamento automático.

– E se o script em algum momento falhar ?

É aí que finalmente deve entrar a força de trabalho humana, lendo os logs do script para detectar o erro, e providenciar a correção dele junto a comunidade que desenvolve o software ou reparando o bug do script para que ele volte a ser autônomo. Também o acordo não iria engessar os desenvolvedores e arrastá-lo para padrões artificiais. Na verdade, ninguém precisa mudar de padrão. Apenas eles precisam ser estabelecidos, listados, fixados, para que os scripts possam ser construídos e funcionarem. Dessa forma, estaremos construindo toda uma cadeia produtiva de lançamento de software livre, caminhando para mais um salto evolutivo nos sistemas operacionais GNU Linux.

UPDATE: Tenho ciência que algumas distribuições mais voltadas para a compilação no ambiente do usuário (como Gentoo e ArchLinux) têm automações parecidas. Não estou aqui sugerindo um processo na relação entre o usuário e o processo de instalação de softwares e sim no processo de empacotamento que a maioria das distribuições Linux fazem entregando ao usuário binários já compilados em forma de pacotes que dependem de intervenção humana. Se observarmos os dados do Distrowatch retirados hoje, temos como distribuições mais populares:

1- PCLinuxOS – RPM
2- Ubuntu – DEB
3- OpenSUSE – RPM
4- Fedora – RPM
5- LinuxMint – DEB
6- Sabayon – Portage
7- Mandriva – RPM
8- Debian – DEB
9- Mepis – DEB
10- Damn Small Linux – DEB
11- CentOS – RPM

Excetuando o Sabayon, todos utilizam essa abordagem manual na criação de pacotes.

Você pode gostar...

46 Resultados

  1. Andre disse:

    Essa é a coisa mais chata no Linux. Para mim, só a palavra compilar dá arrepios. Torço para que esse projeto vá adiante.

  2. Marcos disse:

    Muito bom,ótima idéia!Penso que a parte mais difícil seria conseguir colocar os responsáveis das principais distribuíções para sentar e estabeler o projeto,implementá-lo,etc.Caso este tipo de iniciativa obtenha eco,por quem tem poder de decisão,uma mudança significativa no mundo GNU/Linux se apresentará ao mundo e,na minha humilde opinião,as empresas sentiriam mais seriedade e confiança na plataforma,talvez até mesmo fabricantes de hardware passariam a ver a coisa com outros olhos porque teríamos um padrão estabelecido e aceito por todos.Uma forma de produção otimizada,padronizada e eficiente certamente afastaria de vez a imagem nerd que algumas empresas ainda tem do mundo GNU/Linux.

  3. Rodrigo Amaro disse:

    Parabéns pelo artigo, uma forma inteligente de inserir esta dura discussão sobre padronização no mundo do SL. O mais difícil foi chegarmos até aqui.

  4. Felippe disse:

    Nós já temos a facilidade de instalar com o Ubuntu e outras grandes distros, o que falta agora é otimizar como os mantenedores dessas distros criam seus pacotes, pois realmente é um desperdício de “pessoal”, e vai contra o principio da computação, que seria automatizar processos relativamente “simples”… ótima iniciativa Kurt…

  5. Timóteo disse:

    Excelente artigo, tem algumas partes que eu me perdi, não sei se por erros na pontuação ou se por ser “técnico” demais, mas não importa.

    Quando o linux finalmente se tocar que padrões devem existir, que bagunça pode até dar certo por um tempo, mas logo logo começa a atrapalhar tudo, dai sim ele vai dar um salto pra poder dizer que compete de frente com SO proprietário.

    Eu só usei linux por um tempo (ubuntu), mas toda essa brincadeira de cada distro funcionar de uma forma só faz os desenvolvedores trabalharem a toa e nunca surge um programa realmente BOM e estavel, digno de versão final. Tudo que eu via era programa em testes melhorando um pouquinho a cada dia, dai num deu pra aguentar e voltei pro meu windows. Pode ser feinho, pago, e ter tela azul da morte e virus (não que eu conheça esses dois ultimos, eles são conhecidos distantes para o meu pc) mas pelo menos os softs funcionam muito bem…

  6. Cyberlion disse:

    Finalmente alguém fala uma verdade sólida e que não segue a pura tendência. Desde que uso linux percebo que o sistema só não se torna mais popular pela dificuldade de instalação de programas (a temível compilação). A sua proposta é uma das primeiras que vejo como realmente viáveis para solucionar este problema – muito embora ainda estaremos presos a disponibilidade apenas para os programas mais populares. E é realmente viável porque não visa um único padrão de empacotamento, o que comprovadamente nunca irá vingar, justamente pela liberdade que o software livre oferece.

  7. KurtKraut disse:

    Muito bem esclarecido Cyberlion. Dificilmente as comunidades irão mudar seus padrões e práticas. Isso tem a ver com os valores que têm, a concepção de desenvolvimento que têm, com o que acham que é melhor para o software deles. Mas basta eles esclarecerem isso, definirem um padrão para isso e evitar fugir deste padrão que esses scripts de empacotamento tornam-se possíveis.

  8. Og Maciel disse:

    Buenas Kurt,

    No Foresight Linux possuimos um script (chamado speedbump) que fica sempre “rondando” o site FTP do GNOME por novas versoes. Assim que ele detecta algo nono, ele imediatamente atualiza a informacao na nossa build farm, o que aciona o sistema de compilacao… tudo sem intervencao humana. Ou seja, o que voce almeja ja’ existe… mas o acordo que voce mencionou sobre a padronizacao (e mais importante ainda, o policiamento das regras de padronizacao) e’ o missing link na minha opiniao.

    Bom artigo!

    Og

  9. Kurt,
    como havia comentado contigo antes de escrever esse artigo, o que pensei é algo bem simples: deveria-se estabelecer um padrão XML para descrever o software. Baseado nesse arquivo XML, um programa/script conseguiria detectar o que precisaria fazer para compilar e instalar o software. Assim, ficaria a cargo de cada desenvolvedor mostrar quais dependências seu software requisita, quais são opcionais etc., e ao programa/script de cada distribuição decidir, após a leitura do XML – com ou sem intervenção humana – quais softwares compilar ou não.
    Foi uma simples idéia que tive, mas acredito que muito poderosa: se todos desenvolvedores criarem o tal XML, seria praticamente automático o sistema de baixar, configurar, compilar e gerar o s pacotes de software livre.

  10. O que você quer, o Gentoo Linux e os *BSD já fazem a muito tempo. Sugiro que realize uma experiência com um deles.

  11. J. F. Mitre disse:

    Bem observado.
    Mas eu penso que isso não daria certo.

    Seria muito mais simples propor que todas as distros virassem uma só e que mudassem apenas os logos/nomes e a lista de aplicativos padrões, ou seja, que mudasse apenas a roupa.

    Porque no fundo, bem no fundo, se todo mundo seguir o mesmo padrão, o que muda é apenas aquilo que mencionei acima. Ok, uns usam rpm, outros deb, outro(s) tgz, mas todos esse arquivos servem a dois propósitos, o primeiro compactar para diminuir o tamanho para compartilhar e segundo para resolver o problema das diferenças entre as distros.

    Oras, se não houver diferenças, tanto faz ser for deb ou rpm ou tgz, a diferença será apenas a extensão, por dentro elas serão iguais, iram instalar os softwares nos mesmo lugares, terão o mesmo conteúdo, enfim serão os mesmos pacotes com extensão diferente.

    Aí, quando todo mundo estiver 100% no padrão, não haverá nenhuma diferença nas distros, com a exceção mencionada de logos/nomes e lista de aplicativos que acompanham a iso/cd.

    É como se todas as distros virassem uma só.

    Nota: Acabei de ler o comentário acima do Jeromino Zucco, e é uma verdade e tanto, o Gentoo faz isso a muito tempo, mas nenhuma outra distro segue o mesmo padrão, mesmo sendo o padrão do Gentoo aberto a todos.

  12. KurtKraut disse:

    Olá Mitre,

    Acho que você pegou por um lado da proposta que não é o que eu tentei propor. Não estou sugerindo que distros sejam ‘iguais’ ou tenham ‘a mesma versão de todos os softwares’ nem muito menos que tenham os mesmos softwares. Quero apenas tirar o esforço humano de manualmente empacotar todo o software que usam. Quem escolhe que software empacotar, em que versão, com quais configurações e opções de compilação continuam sendo as distribuições. Só que menos dependentes de intervenção humana.

  13. KurtKraut disse:

    Olá Zucco,

    Fico feliz em saber que os BSDs já tenham esse procedimento e no Linux o Gentoo também. Mas acho que vale a pena o esforço de trazer essa automação para as outras distrubições que já distribuem binários, como o Debian, Ubuntu, Fedora e similares. Há tanta gente doando esforço humano para o processo de empacotar software e o lançamento de versões destas distribuiões seria tão mais ágil se esse processo fosse automatizado o máximo possível.

  14. J. F. Mitre disse:

    KurtKraut,
    Pode até ser, mas eu acho que seria uma conseqüência (não nas versões dos softwares – que é uma questão de política – mas na possibilidade de disponibilidade, exemplo, o slackware poderia oferecer o Gnome mais facilmente, porque não ? Seria fácil empacotar !). E não se iluda, eu acho a idéia muito útil, só não acredito muito nela, pois como você deve saber a própria padronização de diretórios e arquivos (que tem um nome que não me lembro), a muito tempo proposta, ainda não foi adotada por todas as distros.
    []’s

  15. KurtKraut disse:

    Olá Mitre.

    Obrigado pelo feedback. Isso enriquece o assunto. Mas fiquei curioso agora… então você acha que o que faz uma distro diferente da outra é facilidade ou a dificuldade de se empacotar softwares !? Será que o Slackware deixaria de ser Slackware ou perderia suas peculiaridades se ele tivesse fácil acesso ao empacotamento do Gnome ?

  16. J. F. Mitre disse:

    Imagina um mundo onde cada distro contém os pacotes que quer, sem qualquer dificuldade de instalar o que quiser, todos os pacotes poderiam ser adicionados a distro, em qualquer versão idealmente selecionada.
    Todos os aplicativos estão relativamente nos mesmos diretórios.
    Todos os arquivos de configuração estão exatamente nos mesmos diretórios.
    Todas as regras são seguidas por todas as distros. Então o que muda ? O que é diferente ?

    Saindo do mundo do faz de conta e vindo para o real.
    Qual é a diferença entre o ubuntu, kubuntu, xubuntu e todos os membros das famílias *ubuntu ?
    Pacotes que fazem parte da distribuição base e estética.

    De uma você chega a outra com a instalação e remoção de pacotes, não é mesmo ?
    Se todos os pacotes estivessem disponíveis para todas as distros, se todos os caminhos de confs e outras coisas estivessem no mesmo local, a diferença entre o slackware, fedora e o ubuntu seria somente pacotes que estão na base do cd e design. Então com remoção e instalação de certos pacotes seriam possíveis converter entre distros. Exemplo, instalar o ubuntu e instalando o pacote fedora-desktop fazer ele virar um fedora. Porque não ?

    Claro, que essa igualdade só existiria se fosse fácil ter todos os pacotes para todas as distros tão facilmente quanto o que você propõem. Eu digo sempre que eu uso o ubuntu, mas eu tenho todos os pacotes que compõem o edubuntu, o kubuntu e o xubuntu no meu computador, exceto os que definem o tema (como as telas do usplash). Então qual dele eu uso. Eu uso a versão que está escrita no CD ou o que está efetivamente instalado ?

    Hoje, eu até posso ter o fedora-desktop e fazer com que o meu ubuntu fique com cara de fedora, mas os caminhos dos softwares são diferentes (só alguns poucos, ok?). A configuração de certos aplicativos estão propostos de forma diferente (muitas vezes compatíveis com o jeito ubuntu de ser, mas não é o jeito ubuntu de ser). A filosofia por trás da organização do desktop é diferente.

    Sem esquecer que existem conflitos de tipo de empacotamento, ou seja, o deb e o rpm são diferentes, mas interconversíveis (até mesmo nos dias de hoje, quanto mais nos dias que os padrões forem obedecidos)

    Se os padrões forem 100 % seguidos, sem excessão, então sim, o que diferenciaria o slackware do ubuntu seria a disponibilidade de pacotes. Seria fácil ter o gnome no slack, seria possível instalar o slack e transformar em suse e dele depois converter em ubuntu. Seriam os mesmos softwares, as mesmas versões (? caberia parênteses aqui, seriam preciso versões com compatibilidade de cronograma de seus componentes), os mesmo modos de operação, os mesmos caminhos, apenas a estética e a base instalada inicial seriam diferentes.

    É um caso ideal, e claro, minha opinião. Não acredito que essa interconversão ocorra um dia, porque não acredito em padrões sendo 100% seguidos, mas e se fossem, e se fossem… Será que as pessoas que defendem suas distros como bandeiras imaculadas perceberiam que todos nós usamos GNU/Linux ? Que o que é diferente além do logo/tema é a base de software instalada logo após a utilização do CD e que todos os softwares linux estão sempre disponíveis a todos que quiserem ? Quanto a questão humana eu não sei. Tem gente que me julga incapaz de usar uma versão de slack porque eu opto por usar o ubuntu. Então, a pergunta é: Será que a diferença maior entre as distros não são apenas as tribos que compõem cada uma ? Sua ideologias e opiniões ? Porque o software é mesmo, não é ? A despeito de versão é tudo kernel de linux, com pacotes da Gnu, um gerenciador de janelas com alguns servidores (o X inclusive). É só isso … só isso. Discorda ?

    1[]’s

  17. KurtKraut disse:

    Obrigado pela ampla resposta. Me ajudou bastante a entender que você NÃO entendeu o que eu propus 😀

    Não estou em absoluto propondo que todo mundo use o mesmo padrão. Nunca ! Jamais ‘um slackware poderia virar um Ubuntu instalando ou removendo pacotes’. Eu imaginei que isso tinha ficado claro no meu texto, desculpe pela falha.

    Eu vou te explicar o estopim de eu ter escrito isso. Eu estava tentando empacotar o programa vnstat para a distribuição Foresight, que utiliza o sistema de pacotes Conary. Esse sistema ajuda bastanta na hora de criar pacotes. Ele me pede a URL de onde baixar o .tar.gz, a versão desse software e ele baixa, compila e tenta sozinho criar as dependências. Mas estava dando erro, sempre. Investigando o caso, descobri que a falta de um script de configure (o famoso ./configure antes do make e make install) fazia com que o Conary não conseguisse criar o pacote sozinho, porque ele presumia a existência desse arquivo.

    Na minha proposta, o Foresight pediria aos desenvolvedores do vnstat que definissem e esclarecessem qual é o padrão de release deles. Por exemplo, perguntar se eles não pretendem usar o ./configure para instalação. Uma vez esclarecido esse padrão, onde cada arquivo do vnstat fica e o compromisso deles alertarem o Foresight caso isso mude, fica fácil para o pessoal do Foresight criar um script que tem ciência dessa ausência do ./configure e crie pacotes automaticamente sem intervenção humana. Então o vnstat e o Foresight assinariam esse acordo de cooperação em manter essas guidelines para que o fluxo de distribuição do vnstat seja automatizado.

    E se o Debian quiser automaticamente empacotar o vnstat ? O Debian que crie outro acordo com os desenvolvedores do vnstat, pedindo ou combinando suas necessidades ou… podem utilizar o acordo já criado pelo Foresight para se basear e fazer seu scripts (o que é bem provável). Os acordos de cooperação tecnológica, a princípio, envolve duas partes. Uma parte que desenvolve o software que esclarece seus planos e padrão de desenvolvimento e distribuição do outro lado do acordo que, ciente dessas informações, pode providenciar a criação automática dos pacotes. É o caso do Gnome com o Foresight como disse o OgMaciel nos comentários. O projeto Gnome tem guidelines tão sólidas que facilmente scripts foram criados para empacotá-los automaticamente para que entre nos repositórios de teste do Foresight.

    O Debian continuaria usando pacotes .deb, com suas .conf específicas para cada pacote e o Foresight também. Não estou falando em HOMOGENIZAR softwares para o Linux, estou falando em OTIMIZAR o seu empacotamento automatizando aquilo que é possível.

    Espero que tenha conseguido eliminar algumas dúvidas e confusões. Por fim, obrigado por prestigiar meu blog e me ajudar nesses esclarecimentos.

  18. Black_Dragon disse:

    Tenho aversão à palavra PADRONIZAÇÃO, talvez por remeter, independente do contexto, a uma prisão de critérios e ações. É certo que às vezes ela pode ser vista como positiva, por exemplo o padrão PC, porém se falando no mundo software, principalmente no dito software LIVRE, acredito que essa palavra ressoe de forma desgostosa nos ouvidos dos mais tradicionalistas.
    Sem desviar muito do assunto aqui proposto – confesso que não é minha intenção – o linux em si detém uma fama de dificuldade proeminente. Agora, você me pergunta,o que é proeminente? Eu lhe respondo, não tenho a menor idéia, mas o linux é bem isso, poucas são as pessoas que têm a idéia do que ele significa, e é exatamente isso que o faz tão grandioso, tão temeroso por parte de usuários que compartilham da mesma ignorância, no sentido de desconhecer completamente a existência, a essência, do software livre.
    Você talvez esteja querendo fazer outra pergunta, aonde esse cara quer chegar? Bom, eu respondo da mesma forma, não tenho a menor idéia, mas de qualquer maneira, em algum lugar existirá o ponto final, e enquanto ele não chega, a idéia é levar pra frente sempre querendo evoluir. Tornar o processo automático de forma a padronizar critérios pode não ser a saída ideal, mas pensando no que se pode ganhar com isso, talvez a idéia seja tentadora, ao menos para aflorar novas idéias que cheguem senão nos mesmos resultados desejados de uso devido da potencialidade humana em tarefas valorosas, em algo muito maior, que é conhecida como evolução do pensar.
    Lendo os comentários aqui publicados, já posso exemplificar essa evolução. Leiam a reply do Álvaro (Turicas), acredito que é bem por aí…

    Kurt, parabéns pelo artigo, mas.. não gostaria de me ver na figura do Homer Simpsons (ehehhe).

  19. J. F. Mitre disse:

    De fato, houve uma grande confusão na minha interpretação de minha parte. Eu é que lhe peço desculpas. Eu exagerei na interpretação do sentido do “padrão” aqui colocado.
    Nota: já vejo a possibilidade real de não ser apenas uma proposta, quero dizer, é algo simples, pode ser feito e é interessante as partes envolvidas. Resta apenas ser executado.
    [ ]’s

  20. O Slackware usa uma abordagem semi-automática. Ele possui um script para cada pacote (o ilustre desconhecido SlackBuild) que pega os arquivos, extrai, compila e monta o pacote. Porém ele possui interno a ele as informções sobre versão e os fontes, patchs, etc. estão no mesmo diretório. Acho que se quer começar a trabalhar de forma prática nisso, o SlackBuild é o ponto ideal, já que nem grande parte do código do SlackBuild ele é independente da distribuição, apenas no final após todos os arquivos estarem posicionados para se tornarem um pacote, é executado o comando makepkg que cria um pacote segundo o padrão. Outras informações:
    – Se quer scripts para compilar pacotes automaticamente, ele deve ser feito em shell script (apesar de não ter nada contra Python, Perl, etc. shell script é simples de se entender e fácil de ser adaptado)
    – O script pode ser em grande parte independente de distribuição (convenhamos, os binários sempre ficam em /usr/bin, não é?) e no final as alterações referentes a distribuição são feitas.
    – Também deve-se pensar em multiplas arquiteturas (já que certas distros existem para várias arquiteturas), mas o Slackware faz isso de uma forma inicial, podendo se ter uma base.
    – Um problema a ser enfrentado, é o local de onde serão baixados os fontes, já que não existe um padrão quanto a nomenclatura de diretórios. Exemplo: Alguns projetos tem em seus repositórios um link simbólico para a última versão (normalmente o link é o nome do pacote fonte, sem versão). Exemplo: Se existe o projeto FooBar e o nome do fonte da última versão é foobar-1.2.3.tar.gz, pode haver um link chamado foobar que aponte para o fonte da última versão.
    – Meu e-mail é marcosestevesbarbosa SEMSPAM gmail PONTO com, se quisere estou disposoto a discutir aspectos mais técnicos do sistema
    – Uma última sugestão: Uma formulário em PHP para gerar de forma automática os scripts. Então se insere dados como nome longo, nome, curto, endereço dos fontes, flags para compilação, etc. e é gerado o script. talvez até com um menu para as opções que dependem da distribuição.

  21. Creio que o Archlinux seja parcialmente automatizado. Nele, você pode baixar um pacote já compilado pelo pacman ou criar um pacote do source usando o abs.

    O abs baixa scripts (PKGBUILDs) com informações do tipo versão do pacote, endereço do código, opções do ./configure, make, etc., então basta rodar ‘makepkg’ no diretório onde está o PKGBUILD que ele baixa o código, o compila e o empacota; mas o processo de verificar se há uma versão nova ainda é manual.

  22. Renato disse:

    Na minha opinião, o pior defeito do Linux é o atual sistema de instalação de programas por meio de pacotes e gerenciadores de pacotes. Pior ainda é ter que compilar programas para rodar em minha máquina, um verdadeiro absurdo. Sei que muita gente vai me achar chato, mas o Windows e o MacOS possuem sistemas de instalação de programas muito mais simples e práticos. Além do mais, basta baixar UMA SÒ VEZ da Internet o arquivo de instalação que daí em diante eu posso utilizar esse arquivo para em quantas outras máquinas quiser sem que elas precisem estar conectadas a Internet. Ou seja, ambos os sistemas são livres de baixar dependências da Internet para instalar um programa.

  23. Paulo Henrique disse:

    Marcos Barbosa tem razão, SlackBuild seria uma boa saída para este problema.
    Patrick não faz tudo sozinho, mas boa parte das coisas são feitas por ele, muitos acham que é muito trabalho pra uma pessoa só, mas na verdade ele usou o cerebro e agora o empacotamento dos pacotes é uma coisa fácil de se fazer.
    E se eu quiser otimizar uma pacote para minha máquina é só baixar o SlackBuild do pacote em questão e criar o pacote baseado no meu hardware, parecido com o Gentoo e BSD’s, mas não tão automatizado.

    t+

  24. Eitch disse:

    Esse foi um dos textos mais insanos que eu já li em algum tempo. Você não levou em conta de que a maioria das distribuições possuem um buildsystem, que pra facilitar a vida de nós empacotadores, fazem todo o trabalho pesado que a gente teria que estar fazendo. O único trabalho pesado mesmo é criar o arquivo de definição do pacote, o resto é só sair mudando rapidinho as versões e pronto, fácil e rápido.

    Também não levou em conta que não existe uma única forma de se compilar o programa, e nem vai haver, tanto por questões técnicas quanto por questões de gosto. Esse tal de ACT (WTF?) não passa de uma utopia extremamente inviável. Uma das vantagens do software livre é ter essa flexibilidade dos pacotes poderem ser compilados de certas formas. Nunca que tudo vai ser igual. Hoje em dia com a quantidade de pessoas envolvidas, é bem difícil você não encontrar pacotes prontos para as principais distribuições.

    Veja bem, isso não acontece nem no Windows, que dizem que tem os programas fáceis de instalar e bla bla bla. Cada programa usa seu instalador favorito (Installshield, o da Nullsoft, entre outros), tem programas que instalam em “Arquivos de Programas”, outro instalam na raiz mesmo. Uns registram coisas no registro do Windows em um canto, outros registram em outro canto. Uns colocam os arquivos em várias partes do sistema amontoando o bicho, outro mantém tudo certinho em um lugar só e pronto. E um “ACT” nunca vai ser viável no Windows também.

    Então me desculpe, mas achei essa história aí totalmente falha. Se algum dia houver algum tipo de “ACT”, não vai mudar muita coisa porque cada distribuição ainda vai ter que empacotar os seus programas na sua forma e gosto, e isso esses tals “scripts” *nunca* vão resolver. O que vai resolver é uma padronização da hierarquia pra onde os arquivos de programas vão (já existe) e uma padronização sobre como montar os arquivos de especificação da criação dos pacotes.

    No mais, boa sorte, porque na prática isso aí é totalmente falho 🙂

  25. KurtKraut disse:

    Olá Eitch,

    Obrigado pelo comentário. Mas… ‘não vai mudar muita coisa porque cada distribuição ainda vai ter que empacotar os seus programas na sua forma e gosto’. Claro, concordo com você . Afinal, é a própria distro que faria o script, ela modifica o script e por tabela o pacote da forma que bem entender oras 😀 Desculpe se não fui claro no meu post, mas me esforcei para deixar bem claro que não estou propondo que ‘tudo seja igual’, ou que todos adotemos um mesmo modelo, ou que só passe a existir um único modo de compilar um programa. Muito pelo contrário 😀

  26. Sistemas de compilação como o do Gentoo (os razoavelmente conhecidos ebuilds) são preocupados em instalar o aplicativo na máquina (compilando conforme a própria arquitetura da máquina, enquanto o SlackBuild se preocupa em gerar um pacote que será instalado depois, normalmente para 486 (apesar de se notar suporte total a S/390 e parcial a outras arquiteturas). O segredo para essa idéia dar certo seria, acho eu, criar um sistema de criação de scripts (em PHP com interface via web, acho melhor) para criar scripts para a a compilação automática de pacotes. Exemplo: Você entra com informações sobre o pacote Apache e manda gerar um script para Slackware (seria o SlackBuild). Este script, ao ser executado, vai compilar o aplicativo, criar a raiz do pacote e depois gerar o pacote TGZ, que será disponibilizado para download. Idem para o Debian, por exemplo. Neste caso o o aplicativo será compilado e criado a raiz da mesma forma, mas será empacotado em um pacote DEB (não sei qual é o comando no Debian equivalente ao makepkg do Slackware), que será disponibilizado para download. Assim teremos uma compatibilidade boa (já que as distribuições normalmente seguem os padrões FHS e o LSB) entre pacotes. Seria interessante, termos os gerenciadores de pacotes (PkgTool do Slackware, Pac Man do Arch Linux, etc.) disponíveis em vários formatos de pacotes (para Debian, Slackware, Gentoo,etc.) em um único local, assim pode se ter acesso a vários repositórios de pacotes. Isso não envolve scripts, eu sei. Mas a idéia e reduzir o problema de falta de pacotes. Assim o Slackware poderiam ter pacotes compilados segundo a arquitetura como no Gentoo e o Arch Linux poderia ter os vários pequenos pacotes (que eu não gosto, mas…) do Debian.

  27. dfs disse:

    Renato, não entendi o seu problema com o gerenciador de pacotes…Dá pra fazer isso perfeitamente com o linux: pega os pacotes que o gerenciador baixou, leva pra outra máquina e instala ( clique duplo no Nautilus/Konqueror). Na verdade, a grande diferença entre o Windows e Linux no quesito software é que o primeiro é um alvo “parado”. Quando um software é desenvolvido, o programador aproveita uma série de funcionalidades que ele assume como presentes ( as famosas “dependências”). No caso do Windows/OSX a plataforma muda pouco, e empacotar as dependências junto com o programa *geralmente* não dá problema ( mas quando dá…faça um google por “DLL Hell”). Em Linux o programador faz só o pacote dele e anota tudo o que precisa, um segundo programa ( o gerenciador) se encarrega de instalar o programa e eventualmente baixar o que mais precisar. Compilar um programa é uma opção que você tem quando ninguém empacotou *aquele* software pra sua distro. Já pensou se só a autorizada pudesse abrir o capô do seu carro ?

  28. Iron Junior disse:

    É obvio que essa matéria é a que mais vai dar o que falar por aqui…

    Porque????

    Porque é só isso que falta para o Linux (como dizia o Pink e Cérebro) “tentar dominar o mundo”!!

    Sobre o que o dfs disse acima, de “somente uma só autorizada abrir o capô do seu carro”. Eu diria diferente, seria: todos trabalhando pela mesma autorizada… Com toca certeza seria uma grande vantagem para todas as distribuições…

    Resumindo… para mim, só falta isso.

  29. ElCheVive disse:

    Olá,

    Apesar de não ser exatamente o que você pretende, no openSUSE existe o Build Service (https://build.opensuse.org/) que facilita a vida pra quem gera os pacotes, pois o build service gera pacotes para diversas distribuições linux (fedora, debian, ubuntu, etc) além de diversas arquiteturas…É um projeto muito interessante!

    abraços e desculpe o quase “off-topic”…hehehe

  30. Martani disse:

    Eu creio que o Eitch tem razão. A maior parte do que foi dito no texto não faz sentido, pois o que pode ser automatizado já o é na maioria das distros. O Debian, por exemplo, tem ports para um monte de arquiteturas, algumas delas muito pouco usadas, contando com apenas 5 mantenedores *. Mesmo assim, elas possuem milhares de pacotes. Isso é possível pois a maioria dos pacotes tem somente um responsável por empacotar o código-fonte, de forma que este seja facilmente compilável. A compilação em sí se faz automaticamente, em todas as arquiteturas. Se houver interesse, esse responsável pode ser inclusive um desenvolvedor “upstream”, assim “fechando” o ciclo e tornando o tal ACT desnecessário.

    * – http://release.debian.org/etch/arch_qualify.html

  31. Acredito que muitos confundiram as coisas em relação ao seu artigo, de fato o que você diz é completamente coerente, não esta falando em padronizar estrutura de diretórios, nem da compilação do software mais sim das informações a cerca da forma como o programa pode ser compilar certo?

    Agora eu acho difícil isso acontecer por iniciativa das distribuições e principalmente por iniciativa dos desenvolvedores dos Software, não existe um interesse tão claro por partes dos dois, de que esse processo mude, afinal esta funcionando como está, o Ubuntu compila o Gnome com facilidade hoje, a maior parte dos scripts de automação para esse processo estão prontos para essa tarefa, pra que refazer eles e adicionar um processo de checagem intermediaria, não é mesmo?

    Mas ai vem a questão da comunidade, do povo, que quer um processo mais simples para isso, como no seu caso que queria compilar um software a partir dos fontes e não pegar pronto em um empacotamento padrão. Eu acho que seria mais vantajo para nós, usuários finais, um processo desse tipo, do que para as distros, afinal na sua maioria elas são copias dos processo das distros que as antecedem, fazendo um remake do que já existia e adicionando novas funcionalidades mas quase nunca mudando o processo de criação de pacotes (falando em termos de mudanças bruscas).

    Alguns devem conhecer a distro nacional chamada GoboLinux, o Gobo lembra um pouco o processo de empacotamento do Gentoo, mas quando se estuda o processo acaba vendo que existe uma diferença razoável no processo de criação dos pacotes da duas. Mas a questão central no caso do Gobo e que eles criaram um sistema para empacotamento que tem por base um arquivo de configuração que especifica de que forma aquele software pode ser compilado, por exemplo existe uma diretiva básica neste aquivo a recipe_type, essa diretiva identifica se a compilação deve ser feita usando MakeFile, configure ou meta dentre outras opções.

    Eu não sou a favor de muita coisa que tem no Gobo, mas uma possibilidade e usar suas informações sobre compilação de software para startar um processo e criar um serviço que possa prover as informações de uma forma padroniza, como você sugeriu, para que qualquer um possa compilar e/ou empacotar seu software em casa ao seu modo. Ou seja estamos saltando o passo de depender do Fornecedor e do Intermediador para que possamos ter informações padronizadas sobre compilação, estaríamos fazendo o que o Akita gosta de falar: fazendo parte da solução e não sendo mais parte do problema (afinal somo nos que queremos essa possibilidade).

  32. gmazk disse:

    Excelente artigo Kurt. Também vejo medidas em prol da interoperabilidade entre as distribuições como o nosso grande próximo passo evolutivo nos sistemas operacionais GNU/Linux. Grande abraço!

  33. Carol disse:

    quanto mais leio sobre software livre mais um pouco aprendo sobre esse universo ainda não muito conhecido por mim. Gostei do texto pois me ajudou a compreender um pouco mais sobre o processo de geração e distribuição que ocorre! obrigada!

  34. Marcela disse:

    A idéia dos softwares livre é exatamente essa: compartilhamento e contribuição. Esse é o novo paradigma de computação.
    Os próprios usuários não só contribuem com novas versões melhoradas dos sofrwares compartilhando-as com a comunidade, como também ajudam na configuração e no empacotamento dessas versões.
    Por quê não ajudarmos uns aos outros?
    Por quê sempre que “quebramos a cabeça” com alguma atividade difícil, queremos que todos percorram o caminho das cruzes também?

  35. Caio Henrique disse:

    Kurt, concordo e discordo de você ao mesmo tempo.

    Seria sim interessante padronizar esses scripts de criação de pacotes, mas ao passar para o desenvolvedor a responsabilidade de tornar seu software compatível com o script de empacotamento, você estaria passando o trabalho sujo para o desenvolvedor, que teria de fazer várias versões de seu software para cada tipo de empacotador diferente.

    Acho que a única forma de fugir desta “armadilha” seria usar algo como o conceito do java, um intermediário entre o software e o sistema operacional, em que nesse intermediário cada distribuição definiria parâmetros como pastas de configuração e binários.

  36. Isaias disse:

    Realmente evolutiva a idéia! O mundo do software livre sofre com isso. Sua popularização, além das inúmeras distribuições, também sofre com a falta de padronização de seus binários. Tudo isso já foi dito.
    Gostaria mesmo de saber qual é próximo passo.
    • Propor isso em um grande evento Linux?
    • Propor individualmente para cada uma das comunidades citadas?
    • Sair na rua com cartazes?
    Tudo é válido! Mas idéias boas não podem ficar armazenadas em blogs. Precisam sair do papel. Você deu o primeiro passo, precisamos de mais passos!

  37. Gabriel Magno disse:

    Realmente seria muito bem vindo um padrão para automatizar a criação de pacotes para varios distros. Isso seria bom tanto para o desenvolvedor dos aplicativos, que com pouco esforço poderia disponibilizar pacotes, e também para o desenvolvedor da distribuição.

  38. Gostei muito do artigo! Acredito que o desenvolvimento de uma idéia como essa traria inúmeros benefícios para todos os usuários de software livre.

  39. Michelle disse:

    Muito interessante o artigo. Achei que as comparações realizadas retratam muito bem o que é, na minha opinião, o principal gargalo para a evolução e disseminação dos sistemas operacionais GNU/Linux. Gostei muito também da sugestão de criação de um Acordo de Cooperação Tecnológica sem jamais criar um padrão único, ou seja, seria uma forma de simplificar os processos respeitando as especificidades de cada um. E, deixando o “material humano”, tão caro e necessário, para as atividades nas quais ele é realmente essencial.

  40. Olá Kurt!É fato que o software Linux tem muito a se desenvolver. Diante da nossa inserção no mundo Windows tem dificuldade de nos adaptarmos. Somos resistentes ao novo. Acredito que é o nosso papel é contribuir para seu progresso. Quem melhor do que o usuário para descrever, testar e criticar o que ele precisa?

  41. guimaluf disse:

    Empacotamento é um “problema” entre as distribuições. Porém, colocar 2.500 empacotadores debian para mudar o modus operandi de empacotamento é algo tanto quanto complexo. Mas concordo que deveriam existir pacotes genericos para qualquer sabor de unix

  42. Danilo Borges disse:

    Concordo, Kurt.
    Para otimizar o trabalho e aproximar a comunidade que trabalha com projetos de software livre, a criação de diretrizes pode ser fundamental. Um acordo de cooperação tecnológica – desde que não cause, como você bem alertou, a unificação dos padrões de distribuição – certamente contribuirá para a comunidade.
    Assim, além de eliminarmos a necessidade do “trabalho sujo” de alguns corajosos e pacientes voluntários, poderíamos voltar todo o esforço intelectual ao aprimoramento e atualização dos programas.

  43. Luiz Henrique disse:

    A maneira como as distribuições linux disponibilizam os softwares empacotados tem feito bastante sucesso entre os sistemas operacionais em telefones celulares. Quando um usuário de iphone ou android compra um software, ou baixa algum programa gratuito da Apple Store ou da Android Market ele passa por um processo similar ao que acontece quando instalamos um software do repositório da nossa distribuição.

  44. Por enquanto temos que aguardar e agradecer à contribuição das comunidades que comandam as distribuições Linux para que os pacotes fiquem corretamente configurados. Nós usuários utilizamos o software livre com a premissa de que não teremos tanto trabalho para a configuração, mas seria muito mais fácil ferramentas automáticas, restando apenas a verificação de dependência cíclica de bibliotecas de linguagens, entre outras verificações de linguagens de máquinas para os profissionais do Software Livre.

  45. As comunidades de softwares livres devem ficar atentas às mudanças e tendências para que seus softwares não fiquem obsoletos simplesmente por serem de difícil instalação. A força colaborativa dessas comunidades pode sim ser uma importante ferramenta na melhoria da usabilidade desses aplicativos. Elas devem pensar em não somente buscar eficiência e desempenho, mas também na facilidade de utilização e na diminuição do retrabalho.

  1. 04/02/2008

    […] por Kurt Kraut (ubuntuΘkurtkraut·net) – referência […]

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *