Como é bom um sistema unificado: Eu tenho ódio toda vez que vejo um programa que me interessa e ao procurar os pacotes pra baixar, só vejo tar.gz ou .rpm (uso .deb).

É uma coisa meio óbvia, se você é desenvolvedor e tem interesse em ver seu programa usado por muita gente, você TEM que fornece-lo num formato em que qualquer mané (como eu) possa instalar. Pra mim, ./configure , make e make install são 3 piadas. Se um programa instalou na minha máquina com esses comando foi 1 em 300 programas que testei.

Claro que alguém vai dizer aí: "instala as dependências, mané" Mas quem é experiente sabe que nem sempre isso é suficiente pra instalar algo. Sempre tem uma opção da compilação que dá pau na hora de instalar.

Então está dado o recado: desenvolvedores, PELO AMOR DE DEUS, disponibilizem um .package para os "manés" instalarem os seus programas...

"... e não sabendo que era impossível, ele foi lá e fez."

Não basta: O problema é que infelizmente o problema no caso do linux é bem maior do que apenas uma não padronização de formatos de pacotes. O problema é que "linux" não é um sistema operacional, mas tecnicamente um kernel. Quando dizemos "linux" de modo informal estamos nos referindo a uma família de sistemas operacionais, com diferentes versões do kernel e de bibliotecas e programas.

Mesmo que houvesse um único padrão de pacotes binários o problema ainda não estaria totalmente resolvido porque há a questão de dependências de certas versões específicas de certas bibliotecas por causa da geração de binários linkados dinamicamente. Um pacote nesse formato universal nunca teria 100% de chance de funcionar quando instalado em qualquer distribuição linux. Não existe mágica.

O modo windows de resolver as coisas é deixar tudo para o instalador resolver. Ele que traz e copia as dlls necessárias, mexe no registry, copia arquivos, etc. No modo linux típico a ferramenta de instalação de pacotes de nível mais alto baixa e instala todos os pacotes com dependências necessárias para o programa e isso evita a presença de múltiplas cópias de bibliotecas no sistema e economia de disco e memória. Você já viu algum windows com a quantidade de programas que temos numa instalação típica de linux ? E manter um windows atualizado quando o windows update só atualiza aluns programas e cada software muitas vezes tem o seu próprio atualizador, que muitas vezes ainda precisa ser acionado manualmente um a um.

Entendam, o sistema que o windows utiliza para instalação de programas foi projetado basicamente para instalar alguns poucos programas comerciais, que possuem instaladores próprios e diferentes entre si. Os programas são geralmente enormes e auto-suficientes pois o sistema não tem nenhuma modularidade. Os instaladores não permitem muita customização para não amedrontar clientes leigos e seguem a filosofia next-next-finish.

Mesmo no windows há dependências que muitas vezes precisam ser resolvidas manualmente. Quantas vezes o instalador de um programa pede que você instale uma determinada versão do DirectX, do runtime .Net, Oracle client, etc ?

É inviável também distribuir todos os programas instalados estaticamente, em qualquer sistema operacional.

Distribuir o código-fonte do programa é justamente uma das características dos softwares livres e é ao mesmo tempo a forma mínima de distribuição que permita que se execute o programa em qualquer distribuição linux e mesmo em outros sistemas operacionais. Isso não é negativo, muito pelo contrário.

Claro Manoel, concordo: Claro Manoel, concordo plenamente com o que você disse. A verdadeira portabilidade só pode ser alcançada com a distribuição do código fonte. Mas compilar o fonte para alguns usuários é um trabalho "doloroso".

Eu desconheço os detalhes técnicos do projeto do autopackage, mas eu não sei se eles estão indo na direção certa. Criar um "outro sistema" de gerenciamento de pacotes, talvez não seria o ideal para resolver o problema dos diferentes tipos de pacotes.

Acredito que a visão ideal seria um projeto que tivesse sim seu próprio formato de pacote, mas que tivesse a capacidade de converter o pacote para o tipo nativo do sistema(.deb, .rmp ou .tar.gz). Assim, não existiria inconsistências(alguns usuários comuns podem muito bem instalar o amsn pelo synaptic, e depois baixar uma versão mais nova pelo site, no formato .package e ter vários problemas por causa dos arquivos duplicados, usuário leigo SEMPRE faz alguma coisa parecida com isso em busca de versões mais atualizadas), e o autopackage faria um bom trabalho usando o sistema de gerenciamento de pacotes da PRÓPRIA distribuição. Acho muito difícil eles criarem um sistema que chegue perto da estabilidade e da integração do apt-get/dpkg com o Debian.

Uma coisa é uam coisa, e outro coisa é outra coisa: O RPM é padrão. A maioria das distros é compatível com ele. Um deles é o Slackware. Você pode, sem problemas, utilizar um rpm no Slack. Não precisa nem converter nem nada.

A questão é que as pessoas não entendem o q é um pacote. Seja .exe, seja .msi, seja .deb, seja .tgz, .rpm, .tbz (e assim vai), um instalador, ou pacote, sempre tem um arquivo compactado, que é extraído em algum lugar da árvore de diretórios. No caso do Windows, como um programa traz consigo todas as dependências, dlls, etc, etc, etc, você pode instalar um programa onde quiser.
No (GNU/)Linux, como os diretórios são organizados por função (embora isso não seja obrigatório, digo aqui), normalmente a extração ocorre num diretório específico, no caso, o raíz (/).

Mas o fato de um pacote funcionar ou não não depende só disso. Há a questão das dependências, como disse nosso colega, Manuel Pinho. O modo como os binários são linkados com as bibliotecas definem como as coisas funcionam. Quem nunca instalou um programa compilado para uma outra distro, em seguida criou os links necessários (o comando "ldd /usr/bin/programa | grep 'not found'" ajuda bastante) e, quando foi executar o programa, viu em sua frente um erro relacionado à versão da libc? Aí, meus caros, só compilando um pacote para a libc instalada em seu sistema. E surgem os problemas.

Na minha opinião, o RPM é o melhor sistema de pacotes. Independente se vc usa apt-rpm, yum, smart, rpm, ou o que for. É menos chato que o DEB (que eu tenho medo ;-)), e mais completo q o .tgz (defino estes três como os sistemas "clássicos" do Linux).

Para ilustrar o que é um pacote .deb, execute o seguinte comando:
$ ar xv pacote.deb

Você verá vários arquivos, um data.tar.gz, um control.tar.gz, e assim vai.

Eu, como bom usuário do Slackware, procuro sempre compilar os programas que uso. Mas o problema de você compilar não é tanto instalar um programa. O pior é desinstalar. Para isso, não dou um "make install", mas crio um pacote e instalo este pacote. Isso permite um melhor controle do que o make install. E, ao contrário do Clésio Luiz, 1 em cada dez compilações que eu faço falham. Aí eu procuro algum pacote já compilado (conhece o http://www.slacky.eu?) para o Slackware, ou instalo um em formato RPM (genérico, pois os para Fedora, Mandriva ou Suse normalmente não funcionam). Se não achar, me conformo eu não usar o programa, ou pulo da ponte. Até agora me conformei bem ;-) hauahaua

Ah, e o autopackage é excelente. Ele tem um sistema próprio de resolução de dependências, e não precisa que você seja root para instalar. Você pode instalar os programas na sua pasta pessoal (em ~/.local/). Ele tem gerenciamento gráfico (qt ou gtk) e em modo texto.

Ele detecta bem as bibliotecas instaladas por outros meios (se eu sei que tenho a SDL instalada, porque ele vai tentar instalar de novo?), e eu nunca tive problemas com programa algum q instalei por ele.

Enfim.. Para quem gosta de coisas "windows-like", é uma ótima pedida. Pena que distribuição alguma o utiliza como padrão. Um desperdício ;-)

Ah, e conheçam também o paco: (http://paco.sf.net).

Enfim.... Do que estávamos falando mesmo?

---------

Um homem com opinião é sempre um psicopata em potencial.
Aliene-se!

Outra solução seria...: ... a que eu postei em outra notícia: um pequeno arquivo de configuração incluído em cada pacote .tar.gz, a partir do qual se extrairia instruções de instalação, aproveitadas por programas específicos de cada distribuição. Não impediria de instalar manualmente, é um arquivo só, e ainda permite automatizar a instalação da mesma forma que o Autopackage faz, ou seja, o que difere são os scripts que ficam em cada distro e são encarregados de instalar os fontes de maneira adequada àquela distro, enquanto o pacote do fonte permanece o mesmo para todo mundo.



"... e não sabendo que era impossível, ele foi lá e fez."

LSB: O rpm, inclusive, é o formato adotado pelo LSB (Linux Standard base) há um bom tempo

http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html#SWINSTALL-INTRO

Ou seja, cada distribuição pode até ter um formato diferente de pacote mas tem que ter suporte a rpm para ser ser compatível com a LSB.

Mas mesmo entre as diversas distribuições que usam rpm nativamente um pacote rpm de uma distribuição funciona na outra ou mesmo entre versões diferentes de uma mesma distribuição. Mas se o pacote rpm for bem feito tem uma grande chance de funcionar em qualquer distribuição. O Opera e o Skype, por exemplo, fornecem rpms e nunca tive problemas para instalá-los. No Opera, se não me engano, há até um dos rpms que vem com a biblioteca Qt linkada estaticamente para evitar essa dependência.

Opera...: Coincidentemente estou com problema em uma máquina com Fedora 8, em que instalei o Opera, usando um pacote rpm para essa distribuição. Engraçado é que instalei em outras três máquinas e tudo funciona perfeitamente. Mais engraçado ainda é que a máquina que deu problema teve sua instalação clonada de outra que funciona perfeitamente (com dd). Instalallei o mesmo pacote nos dois pc's e em um deles mesmo tendo instalado normalmente o opera não inicializa, dando alguns erros de biblioteca que não me lembro agora... Enfim são coisas estranhas que só os computadores e as mulheres proporcionam. ;)

Talvez por isso goste tanto dos dois.

Um abraço.

=======================================================

LIBERDADE, IGUALDADE E FRATERNIDADE!

deb: Pacotes deb são melhores pois resolvem mais problemas do que pacotes rpm. Se você tem medo deles é porque não os conhece bem ;)

Você provavelmente nunca criou pacotes nos dois sistemas, e posso dizer que criar pacotes deb é bem mais simples e flexível.