Padrão de pacotes no linux é INDISPENSÁVEL!!! junte-se a essa revolução !!

[zoroastro]

ah cara... sei lá viu... eu, na minha opinião, acho até bom que não tenha esta "padronização", porque se padronizar, tudo começar a ficar muito igual...

[_Luks]

poderiam haver scripts para instalar pacotes rpm atraves do alien e scripts para instalar tgz,tar.gz e bz2

converter pacotes .rpm com o alien, nem sempre dá certo, dando uma idéia de gambiarra

[vinicius_aleao]

ah cara... sei lá viu... eu, na minha opinião, acho até bom que não tenha esta "padronização", porque se padronizar, tudo começar a ficar muito igual...

Num acho que vá ficar nada igual, não. O que se está discutindo aqui é a padronização de pacotes, não de sistema. Como já foi dito antes, todas as distribuições poderão continuar com seus pacotes próprios, a única diferença é que aceitarão também um pacote padrão. É a mesma coisa das extensões dos arquivos: a ISO padronizou o ODF, e o Office 2007 da MS já aceita esse padrão, além de suas extensões proprietárias. Ainda assim, o Open/BrOffice é bastante diferente do Office 2007. Não tem nada a ver uma coisa com a outra.

[s4suk3]

Eu, particularmente, sou contra.
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros. Aqui no arch, eu uso o Pacman, que é extremamente interessante, mas não trabalha com deb nem rpm.

Liberdade de Escolha prevalece, na minha opinião.

[Nossile]

Penso que o suporte a um padrão é nescessário sim, os mantenedores de distribuições não precisam abandonar seu sistema atual, não é impossível suportar dois sistemas de pacotes.

E mesmo que todas abandonassem o antigo isso não afetaria a liberdade do usuário, pois essa não está no fato de usar .rpm ou .deb e sim ter acesso ao source.

[Komodor]

Eu, particularmente, sou contra.
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros. Aqui no arch, eu uso o Pacman, que é extremamente interessante, mas não trabalha com deb nem rpm.

Liberdade de Escolha prevalece, na minha opinião.

sabe porque existem falhas? porque eles não se juntaram para fazer nada! pois assim nunca irá ter um pacote para todos que funcione perfeitamente.agora se os caras que comandam as distros se juntassem para fazer ai esses bugs não existiriam

"e a souce para outras distros"
peça as sources de um software privado (como um jogo por exemplo ut2004) para ver se eles irão te mandar

"Liberdade de Escolha prevalece, na minha opinião."
amigo você chegou a ler todo o artigo? a padronização não faz com que deixem de usar os outros pacotes!! mas cria um em que o programador possa ter certeza que irá funcionar em qualquer distro sem bugs (pois esse pacote irá ser feito pelas distros,ai que esta o funcionamento sem bug).

num caso hipotético que esse padrão fosse feito,você teria a opção de lançar neste pacote ou senão nos outros. mas para alguém que não trabalha com um grupo grande não vai preferir criar pacotes individuais para cada distribuição,sendo que aquele padrão irá funciona nas outras sem problema

sempre liberdade de escolha,isso nunca irá mudar em gnu/linux

[glaubergoncalves]

Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros.

Liberdade de Escolha prevalece, na minha opinião.

   São coisas que eu também levo em consideração... se eu der minha opinião pessoal, vou dizer que pacotes Debian são a melhor escolha para ser a base de um padrão único, visto que minha experiência com eles é muito satisfatória. Mas quem tem preferência por pacotes RPM com toda a certeza vai discordar de mim, provavelmente enumerando as vantagens deste tipo de pacote e porque ele deveria ser tomado como base para uma padronização. A pluralidade de pontos-de-vista e as múltiplas formas de se montar um sistema no Linux leva à estas variedades, é difícil querer estabelecer um padrão único para algo que é intrinsecamente diverso.

   Quanto à comparação com o ODF, existem sensíveis diferenças. O caso é que já existe um padrão "de facto" para edição de documentos atualmente, que é o formato proprietário da Microsoft. O problema aí é que este é um formato fechado, não há possibilidade de se seguir este padrão, porque não é possível conhecer suas especificações. Vendo por este ângulo, sequer se trata de um padrão, já que não pode ser seguido! O ODF vem a corrigir esta distorção, lançando um padrão de documento aberto, passível de ser utilizado por qualquer suíte office.

   Pois bem, apesar de não ser único, acho que os formatos de empacotamento que temos no Linux de certa forma são padrões, visto que são abertos e passíveis de adaptação. Vejamos a definição do termo padrão dada pela ISO, extraída da Wikipédia:

"(...) um padrão é um 'documento aprovado por um organismo reconhecido que provê, pelo uso comum e repetitivo, regras, diretrizes ou características de produtos, processos ou serviços cuja obediência não é obrigatória'".

   Não sei dizer se os tipos de pacotes são aprovados por algum organismo reconhecido, mas eles são de uso "comum e repetitivo", cada um dentro de seu contexto. A obediência à eles também não é obrigatória, visto que por sua natureza open-source, são passíveis de adaptação, ou inclusive podem ser substituídos um pelo outro, ou ainda por um terceiro (alguém que, por exemplo, cria uma nova distro baseada em outra anterior, substituindo seu programa gerenciador de pacotes).

   Compreendo a necessidade de quem necessita do estabelecimento de um padrão de empacotamento para distribuir softwares no Linux, inclusive um tempo atrás ví algo no blog do Flash para Linux que falava a respeito disso. É uma necessidade importante para produtores de soft proprietário, que por não abrirem suas especificações não podem simplesmente entregar seus programas para as distros empacotarem. E claro, para desenvolvedores menores, como frisou o Komodor anteriormente, não deve ser tarefa fácil manter um número tão variado de pacotes, compatível com tantas distros... Mas até pela natureza livre do sistema, onde geralmente padrões não são impostos "de fora pra dentro", e sim ao contrário (o uso condiciona o padrão, ao invés do padrão condicionar o uso), esta padronização pode ter um grande desafio pela frente...

   Enfim, acho que o SL esta sempre aberto (por natureza) à demanda de quem necessita dele, e mesmo que não surja um padrão universal para pacotes, à medida que a demanda por programas que precisem de um determinado padrão para distribuição atinja massa crítica, acredito que pode brotar algo que dê conta desse recado.

[vinicius_aleao]

Quanto à comparação com o ODF, existem sensíveis diferenças. O caso é que já existe um padrão "de facto" para edição de documentos atualmente, que é o formato proprietário da Microsoft. O problema aí é que este é um formato fechado, não há possibilidade de se seguir este padrão, porque não é possível conhecer suas especificações. Vendo por este ângulo, sequer se trata de um padrão, já que não pode ser seguido!

Não sei se o colega entendeu minha comparação. Tudo isso que você falou em relação ao ODF e doc é verdade e eu já sabia. Eu sei que há diferenças, mas eu comparei apenas para mostrar que a existência de padrões em nada interfere na escolha individual de cada um. Eu poderia ter comparado com qualquer outra coisa, era apenas uma ilustração.

sabe porque existem falhas? porque eles não se juntaram para fazer nada! pois assim nunca irá ter um pacote para todos que funcione perfeitamente.agora se os caras que comandam as distros se juntassem para fazer ai esses bugs não existiriam

Perfeito, Komodor. Essa campanha em favor de padronização de pacotes (que, repito, nada tem a ver com padronização de sistemas) deve ter como objetivo sensibilizar os mantenedores das distros para que escolham e passem a aceitar TAMBÉM um tipo de pacote padrão. E para isso, eles têm que se reunir e fazer acontecer.

[alexcunha]

É conhecida alguma outra iniciativa internacional com o mesmo propósito?

[Piras]

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.

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.

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.

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.

Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.

[boi]

Uma coisa que acho que muita gente ainda não entendeu é que é perfeitamente possível ter pacotes de software pré-compilado que funcionam em qualquer distro. O Opera, por exemplo, tem pacotes para várias distros, mas também tem uma versão compilada estaticamente que funciona em qualquer distro. Essa versão existe tanto em RPM como em DEB, mas também num simples pacote tar.gz que pode ser usado até em distros que não suportam esses formatos de pacotes, é só descompactar e usar. Se o formato RPM fosse mesmo suportado por todas as distros, então eles nem precisariam distribuir em deb e tar.gz. Eles e qualquer outro produtor de software fechado poderiam simplesmente distribuir apenas um pacote RPM compilado estaticamente, que poderia ser instalado em qualquer distro. E caso tivessem interesse poderiam fazer, como o Opera faz atualmente, pacotes específicos, compilados dinamicamente, para as distros mais populares.

[vinicius_aleao]

Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.

Desculpa, mas não sei o que tem a ver...

[glaubergoncalves]

Não sei se o colega entendeu minha comparação. Tudo isso que você falou em relação ao ODF e doc é verdade e eu já sabia. Eu sei que há diferenças, mas eu comparei apenas para mostrar que a existência de padrões em nada interfere na escolha individual de cada um. Eu poderia ter comparado com qualquer outra coisa, era apenas uma ilustração.

Compreendi Vinicius. Apenas peguei o gancho da tua ilustração pra trazer à tona essa questão da padronização e de como ela pode ser vista em diferentes contextos.

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!

Constatação interessante, Piras.

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.

Exato. Diferente do Windows ou do Mac OS, as distros Linux primam por sua especificidade, penso que existe um fino equilíbrio entre cada um de seus componentes, e as características de cada uma delas pode ser definida por este equilíbrio. O tipo de pacote utilizado é apenas mais uma peça deste processo, tão fundamental quanto todo o resto.

Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.

Penso que são sistemas diferentes, e diferentes paradigmas...

Uma coisa que acho que muita gente ainda não entendeu é que é perfeitamente possível ter pacotes de software pré-compilado que funcionam em qualquer distro.

Cara, instalei o Googleearth através de um destes "genéricos" (acho que era um .run) e a instalação foi fácil e fluída, tanto quanto é o funcionamento do programa. Abri o Nautilus como root>>duplo-clique no .run>>executar em terminal... instalado.

[Komodor]

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

[boi]

Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.

Piras, isto é absolutamente verdadeiro, e já disse isso várias vezes nesse fórum. Mas você erra em achar que é impossível um pacote universal, que funciona em qualquer distro. Isto tanto é possível que já existe.
Mas o problema maior é que muitas pessoas querem que simplesmente seja extintos os sistemas de pacotes do Linux, e seja adotado algo parecido com o Windows. Mas aí é porque essas pessoas não só não conhecem Linux, como nem sabem como isso é feito no Windows. Pensam que no Windows existe um padrão, quando na realidade é uma bagunça, cada desenvolvedor faz o que quer. É comum, inclusive, esses instaladores substituírem as bibliotecas do sistema por versões próprias, resultando muitas vezes em instabilidade do sistema e lentidão, quando não em surgem incompatibilidades com outros softwares. Falam do que não conhecem. O próprio "artigo" citado no início do tópico é muito ruim, e veja que citaram até a tal de Fabiane não sei das quantas. Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça.