Para mim, esta é uma discussão bastante simplista. O problema não está no formato do pacote, se RPM, DEB, TGZ, TAR.GZ.PKG, etc. Como foi dito acima, se duas versões do sistema são incompatíveis, não há pacote que resolva. O ramo unstable (Sid) do Debian também usa os mesmíssimos pacotes DEB do ramo estável (Etch), mas os pacotes de cada um deles podem ser incompatíveis simplesmente porque se trata de versões diferentes e pronto! Um Ubuntu lançado em outubro de 2007, com o Gnome 2.20, não será compatível com o Debian Etch, que foi lançado no início deste ano, ainda com o Gnome 2.16! E o problema das dependências: uma distro menos focada no conforto pode até mesmo aceitar o controle de dependências (com a instalação automática das mesmas), mas é bem possível que o pessoal do Slackware, por exemplo, acredite que o mesmo programa exija muito menos dependências que o pessoal do Ubuntu atribuiria ao mesmo. E o tipo de pacote - DEB, RPM ou TGZ, - tem muito pouco a ver com isto.
veja o caso do autopackage.
http://www.autopackage.org/
estes pacotes vão instalar tanto no meu ubuntu,quando no gentoo do meu amigo,quando no fedora,slack,etc.
distribuições totalmente diferentes! (ou você acha que não?) funcionam! o que ocorre é que você esta comparando deb,rpm,.tar.gz (puts da pra ve que tu não entende nada ao comparar o .tar.gz)
como eu ja disse trilhões de vezes. o deb,rpm,são pacotes diferentes... sem a POSSIBILIDADE de se fazer um pacote multi-distro.
eles só pegam os binários dentro do pacote,e colocam a pasta especificada de instalação. o que mais ele faz é verificar as dependências. não tem INTERFACE GRÁFICA!,NÃO TEM COMO PEDIR SERIAL OU ATÉ MESMO O LOCAL A INSTALAÇÃO.comparar um rpm e um deb por não funcionarem em varias distros é totalmente sem cabimento.
o que vocês pensam é que seria só um pacote como um rpm ou deb e se renomeia para algum outro nome e pronto,se fosse isso ninguém iria estar perdendo tempo aqui. a questão é que o pacote tem que ser como um autopackage desenvolvido pelas distros,é possível sim funcionar em qualquer distro basta ter a coperação entre eles
é obvio que pode ter problemas que alguns programas não funcionem em todas as distros. se tu faz um programa para interagir com o gnome e tu não tem gnome não irá funcionar,é obvio! mesma coisa que tu criar um jogo para rodar o som em ALSA e a distro só aceita OSS.
a questão é que hoje em dia com rpm,deb,etc nem se tu tem todos os componentes da mesma versão irá funcionar de uma para outra distro,com uma padronização claro que iria funcionar se a distro estivesse com os requisitos especificados pelo padrão
O que muitos não percebem é que a única forma que o Windows encontrou de resolver o problema foi tornar cada uma de suas versões totalmente compatível com as outras. Mas isto sempre deu tanto trabalho ao desenvolvimento deste sistema que terminou sendo parcialmente abandonado pelo Vista: muitos executáveis do XP simplesmente não funcionam no Vista, exatamente, aliás, como boa parte dos pacotes do Debian Sid não funciona no Etch.
uma coisa que vejo que tu não tem idéia do que fala é que os programas do windows,em 98% dos casos não é um pacote instalador,e sim pura e simplesmente um executável,pois o windows não tem variantes irá funcionar sempre,se tu tem winxp,compilar para ele o outro que tiver vai rodar também.
o kernel do xp pro vista teve uma mudança completa.isso faz com que o sistema não tenha compatibilidade, o que no caso do linux.tu vai criar o programa para o kernel 2.6 em muitos casos até para 2.4 em diante. o kernel não se modificou todo a esse ponto,a maioria das distros usa o 2.6 (uns 95% pelomenos)
um pacote instalador não é um executável,ou você achava que os (.exe) do windows erão pacotes?
Portanto, a existência de um pacote padrão dificilmente resolveria o problema da incompatibilidade entre distros distintas. Os pacotes adequados a uma distro que privilegia a atualidade dos programas (como a Arch, Ubuntu, etc.) seriam sempre incompatíveis com aqueles outros de uma distro que privilegia a estabilidade (como o Debian, Slackware, etc.). E é bom que isto continue assim.
explique-me o porque os programas em autopackage funcionam em muitas distros,sem edições nem uma?
ou intão os programas com (.bin) e os (.run) vou citar alguns:
IBM Symphony
Unreal Tournament 2004
Doom3
etc.
realmente devo estar bêbado esses programas não existem...
Desse modo, se todas adotassem o RPM, ainda assim haveria a necessidade de um RPM para a Suse, outro para a Fedora, outro para a Yoper e assim por diante. A vida só ficaria fácil mesmo para o desenvolvedor, que teria que aprender a empacotar apenas no formato RPM. Não sei se é uma vantagem que vale a pena, ante os prejuízos sofridos pela natural diversidade do mundo Linux.
como eu disse o RPM seria impossivel de se fazer qualquer coisa deste modo,o que ocorre,é que vocês não leem todo o tópico vem na ultima pagina sem entender nada e ficam falando umonte de abobrinha
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
sem comentários.....
Komodor,
Sua observação a respeito do meu "nada entender" pelo fato de citar o tar.gz só revela que sua leitura é desatenta. Eu citei, não o TAR.GZ e sim o TAR.GZ.PKG,
que é o pacote binário da Arch. Seja mais atento e mais educado, sim. Não é preciso desqualificar a pessoa de quem se discorda, mas apenas refutar o seu argumento em si mesmo.
E o que você não entende ao citar o
autopackage é a redundância que ele acaba gerando. O autopackage só funciona em todas as distros porque cada pacote instala por padrão todas as suas dependências, independentemente do que já existe no sistema. Logo, ao instalar vários pacotes destes no seu sistema você terá em pouco tempo um bocado de bibliotecas e programas
redundantes (vale dizer, duas ou três bibliotecas e programas em diferentes versões, pois é esta a razão do "milagre" do mesmo pacote funcionar num Slackware e na Arch Linux). Não há milagres no que respeita a este problema, meu caro. O que se ganha de um lado, se perde de outro. A questão é que você só percebe - empiricamente - que o
autopackage funciona em qualquer sistema, sem perguntar-se porque isto acontece. É ao ir mais a fundo que se percebe os poréns desta proposta.
*-*-*-*-*
Se você der uma olhadinha neste ligeiro tutorial sobre o autopackage
http://www.guiadohardware.net/tutoriais/dominando-autopackage/, você verá que o autor diz claramente:
Ele (o autopackage)foi criado para instalar apenas programas não-essenciais, como processadores de texto, navegadores, jogos e outros, já que para pacotes essenciais, é recomendável o uso do sistema nativo, para melhor velocidade e compatibilidade.
E por que é recomendável o uso do sistema nativo em relação aos programas essenciais? Bem, o próprio autor o diz implicitamente, ao afirmar que o
o Autopackage verifica a presença de dependências no computador, bem como examina as informações do pacote, e isso reduz a incompatibilidade entre diferentes padrões de distribuições.
Reduz, não supera.
No tópico dedicado ao tema na Wikipedia também se afirma que
Autopackage se diferencia de otros sistema de instalación como Loki installer en que Autopackage está especialmente diseñado para ser compatible con tantas distribuciones como sea posible.
Vale dizer, não é verdade que se trata de um instalador realmente universal. Quanto mais ampla for a compatibilidade do
autopackage maior será o tamanho dos respectivos pacotes, pois maior será a quantidade de dependências a serem instaladas por padrão.
Em outras palavras, o autopackage pode ser perfeitamente adequado para permitir, por exemplo, que um aplicativo não-essencial e menos dependente das bibliotecas básicas do sistema seja instalado sem maiores problemas. Seria muito conveniente, aliás, que programas como Opera, Frostwire, Exaile e Amule, dentre outros, sempre tivesse um
package disponível em seus sites na Internet. Mas eu sou muito cético quanto a possibilidade dele ser gerenciador de pacotes padrão de qualquer distro.
Exemplo disso é o PC-BSD, cujos pacotes secundários são oferecidos na forma de PBIs. Bem os PBIs são apenas uma adaptação do
autopackage, funcionando da mesmíssima forma, ou seja, através de simples
scripts em
bash (pois cada
package não passa de um
script em
bash a qual são somadas diferentes interfaces gráficas). Ora, todo o sistema (que não passa de um FreeBSd pré-configurado) é construído através do tradicional sistema de ports do BSD, com seus próprios pacotes TGZ. Só alguns poucos pacotes suplementares estão disponíveis na forma de PBI, quase nada se comparado a base do sistema.
Portanto, eu nada tenho contra o autopackage. Até acho que ele é uma proposta bem interessante, que poderia ser melhor e mais usado. Mas, nem de longe, o considero adequado como um sistema de gerenciamento de pacotes padrão. Aliás, acho muito discutível que o tal "sistema de gerenciamento de pacotes padrão" seria realmente necessário. Mas, se for o caso, acho que há candidatos muito melhores, como o
pacman e, sobretudo, o
Conary, que estão léguas à frente do autopackage em sofisticação tecnológica, por menos que eles pareçam com um
exe. do Windows.
