Packagekit como front-end universal?
“Sendo uma das primeiras distribuições a utilizar o Packagekit, o Fedora novamente demonstra sua postura inovadora, porém com a cautela devida, apostando em ferramentas que tenha perspectivas de amadurecimento ou que sejam utilizadas como padrão pela comunidade Open Source. De acordo com Richard Hughes, colaborador do projeto Gnome, essa ferramenta poderá ser utilizada com front-end universal entre todas as distribuições e assim criar mais uma camada de abstração para o usuário.
O Packagekit foi adicionado ao Fedora na versão 9 e foi convencionado como padrão dessa distribuição desde então.
Enviado por Rafael Gomes (rafaelgomesΘprojetofedora·org) – referência (projetofedora.org).
• Publicado por Augusto Campos em
2008-07-01
@brlinuxblog
Feed RSS
É interessante,mas deveriam equilibar um pouco reduzindo a dependencia de repositórios centralizados,pois é um desperdício de recursos vc puxar mais de 400 mb de downloads e não poder distribui-los para as pessoas que usam outras distros GNU Linux.
Um projeto interessante e independente de distribuição.
http://0install.net/
E ainda por cima dá pra compartilhar os downloads puxados!
Eu ainda acho muito mais interessante a alternativa do klik2, que lembra um pouco, o esquema de distribuição de programas no mac, onde você tem um arquivo .dmg que é uma imagem da aplicação, e para instalar é só copiá-la para seu computador. Simples, fácil, e sem aqueles next-next-finish imbecis.
Vejam o vídeo:
http://liquidat.wordpress.com/2007/09/06/klik2-a-new-linux-installer-for-the-masses/
e a documentação:
http://klik.atekon.de/wiki/index.php/Klik2
ps: mac haters: não é uma cópia do esquema de instalação do mac, muito menos foi baseado no mesmo, para falar a verdade é uma tecnologia bem diferente, só que no final das contas o paradigma de instalação acaba sendo parecido, por isso a minha comparação
Pessoalmente eu adoro essa apresentação:
http://klik.atekon.de/presentation/
A ideia é boa, mas nunca poderemos usar pacotes de uma distro em outra visto que os pacotes são compilados com dependências diferentes.
Não basta um instalador ou um sistema de repositórios universal seria preciso que as dependênicas fossem a mesma, mas isso é inviável, já que o chamariz e a vedete das distro é poder dizer que tem um pacote mais recente do que a outra.
O dia que isso ocorrer todas as distros Linux se reduzirão a uma só, ou eentão teremos gigantescos binários compilados estaticamente.
Não é bem assim .A idéia é usar um sistema alternativo ao repositório centralizado.
É possível reutilizar os fontes sim.
Olhe nos projetos acima e verá.
Acho muito interessante o autopackage, que seja talvez o primeiro sistema para Linux que funcione independente de distro, podendo inclusive ser instalado sem a intervenção do root. Cada instalador é independente (basta dar dois cliques ou chamar via linha-de-comando) que abre um instalador ao estilo Windows (next-next) que tem inclusive checagem de dependência. Mas esta checagem é mais “inteligente”, por assim dizer, já que se você já tiver na sua distro o pacote abc, ele verificará se existe o arquivo necessário para a instalação, mesmo que não esteja na base de dados do sistema de instalação. É o oposto do que ocorre, por exemplo, nos gerenciadores de pacotes como dpkg/apt e rpm, onde, mesmo que o programa esteja instalado, o sistema busca somente em sua base de dados. (pacote não encontrado: libc :-)).
Acho interessante estas iniciativas, mas parece que elas dificilmente vingam ou ganham tanta popularidade quanto os sistemas atuais das distros.
Como disse o colega acima, uma solução alternativa à que utilizamos nas distros atuais (dependências e fragmentação de coisas) é distribuir cada programa com tudo que ele precisa já incluído, como no Windows ou OS X. Mas aí já viu a confusão que vai ficar, além da enormidade de espaço ocupado no HD ou consumo de memória. Por exemplo, distribuir a GTK+ em todos os programas que a utilizam deixaria um rastro de redundância inimaginável. Aquele programa que depende de dezenas de pacotes, mas que tem somente 200k de tamanho ficará com mais de 10MB :-)
Nenhuma distro vai abandonar rpm ou deb, isso não tem jeito, também cada qual com a sua politica de versoes. Já que é para ser assim então seria interessante que programadores/times/companhias tivessem um repositório para seus fontes e disponibilizassem arquivos XML detalhando dependencias, descrições, etc… assim cada distro ou usuario comum poderia fazer um BUILD para seu sistema deb/rpm/whatever. Hoje isso até existe, mas chama-se ./configure && make && make install, mas sem as dependencias.
Hoje é o samba do crioulo doido, cada qual com sua versão, dependencias diferentes e estranhas. No meu ubuntu, eu não uso o evolution, mas se eu remover o evolution-data-common ele me leva embora metade do gnome. É desanimador ver que as mainstreams não querem melhorar esse dilema.
Nossos “vizinhos” do PC-BSD têm o formato de pacote PBI, que faz justamente isso. Os arquivos instalados a partir de um PBI ficam organizados em uma estrutura de diretórios que lembra muito a do GoboLinux. Será que alguém já pensou em portar o PBI para Linux?
Falando em GoboLinux, uma opção promissora para quem quer instalar programas “fora do padrão da sua distribuição favorita” é o GoboLinux Rootless, que configura uma sub-árvore GoboLinux, instala seus pacotes e compila suas receitas diretamente na sua pasta pessoal (ou em alguma outra que você escolher), sem estragar o seu sistema. Ainda não testei suficientemente bem o Rootless, mas ele tem potencial: instalado num pen-drive, por exemplo, seria uma alternativa Linux ao projeto PortableApps.com.
O Packagekit é muito interessante.
O OpenSUSE 11 também usa ele como front-end para o openSUSE-updater, em conjunto com o libzypp.
Assim como o tenchi também gosto muito do autopackage, que é bem eficiente, só discordo com o parte da verificação dos gerenciadores em rpm, a libzypp verifica todos os pacotes no hd, por isso antigamente era bem lenta pois sempre “montava uma nova base” toda hora que entrava no programa, hoje melhoraram o algorítimo e está bem rápido, porém se vc instalar o programa via outro gerenciador de pacotes, ou via source, ou simplesmente colocar manualmente tais aquivos em suas respectivas pastas manualmente o libzypp vai resolver dependências com esses aquivos.
Isso sem contar no SUSE.conf que faz uma “reorganização” nessa base e em todos os aquivos de configuração após a instalação de cada aplicativo (scrips como SUSE.conf.fonts/ SUSE.conf.gtk, etc…)
Voltando ao assunto do tópico, acho que é bem interessante um gerenciador universal, porém como já mencionado isso só vai funcionar for possível ter um repositório centralizado unificado.
Por essas e outras também gosto muito do projeto openSUSE build service, que gera pacotes pré-compilados para diversas distros (entre elas, fedora e ubuntu) a partir de um único source e também os sources rpms compatíveis com qualquer distro, pois suas dependências são relacionadas a arquivos e não a outros pacotes. A ideia do projeto é ter um repositório unificado para todas as distros, e manter todas as distros sempre bom as ultimas versões de cada pacote.
Me corrijam se eu estiver errado, porém esse projeto 0install, citado acima, não é a mesma coisa do source rpm? Ou seja, um único fonte que pode ser usado em qualquer distro independente do sistema de dependências? Eu sempre usei os sources rpms disponíveis no fedora no suse e vice-versa! Só não costumava funcionar em alguns sources do fedora que a dependência era setada para um certo pacote e não para um certo arquivo, de qualquer forma para isso existe o build-service!
Paulo Cesar, me corrija por favor, porém até onde eu entendi esse klik2 na pratica não tem nenhuma diferença dos atuais sistemas deb e rpm, a diferença é que ele já possui as dependências junto ao pacote, não? Isso também pode ser feito nos sistemas deb e rpm! E também já existe um sistema de imagens para rpm que inclui cada dependência como um pacote diferente ao sistema (o mesmo usado no novo instalador do suse)
Hamacker, é disso que vc está falando? Se sim, basta usar! Acredite ou não com quase um ano e meio de existência do projeto só vi pacotes gerados para o fedora lá estava setado como privado.
Bem, projetos para “unificação” do sistema de instalação no Linux vão existir por muito tempo, difícil é saber se algum realmente vai ganhar pernas…
O openSUSE build service é muito bom, porém só por ter o nome suse no meio já vai ser descartado por muita gente hehe!
O zero install , instala binários também sem necessitar de permissão de administrador e é possível utilizar os binários em outro sistema desde que o outro também tenha o zero install .
Ah, esse é um ponto bem interessante para o zero install.
Porém aplicativos que não necessitam de permissão do root para instalação geralmente são distribuídos em tar.gz e são descomprimidos na pasta do usuário. Como é o caso do Blender.