Entrevista com os programadores do PackageKit
“O PackageKit (http://packagekit.org/) deve tirar a dor do gerenciamento de pacotes em sistemas GNU/Linux e criar um sistema que possa competir com o Windows e Mac. O Desenvolvimento está sendo realizado a largos passos e acredita-se que poderá estar presente no Fedora 9. Para conhecer melhor, o Projeto Fedora entrevistou Richard Hughes (https://fedoraproject.org/wiki/RichardHughes) e Robin Norwood (https://fedoraproject.org/wiki/RobinNorwood), os donos da nova funcionalidade do Fedora.
Trecho:
O que te motivou para inicializar o Projeto PackageKit?
Richard Hughes: Toda distribuição reinventa o mesmo tipo de ferramenta de gerenciamento de pacotes, e geralmente faz isso muito mal. O front-end do gerenciamento de pacotes são quase sempre mal localizados ou traduzidos para uma distribuição específica. O Fedora tem o pup e o pirut, Ubuntu tem o gnome-app-install e update-manager, e o Suse tem o programa de linha de comando libzypp e o zen updater. As outras distribuições basicamente colocam alguma interface gráfica sobre essas ferramentas de gerenciamento. Para competir com o Windows XP e o OSX, precisamos melhorar o que temos a oferecer no Linux, mesmo com sistemas totalmente diferentes como o gentoo com ebuilds e o Fedora com rpms binários.
Robin Norwood: Eu não poderia concordar mais. Também, devo adicionar que os desenvolvedores de aplicações que queiram instalar plugins ou adições no software, devem ter o benefício de utilizar uma API de empacotamento unificado.”
Enviado por Rodrigo Menezes (menezesΘprojetofedora·org) - referência (rmenezes.orgfree.com)..
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Manoel Pinho
18/01/08 13:17 - usuário registrado #8
repositórios de pacotes: Concordo contigo que não vejo nenhum problema com o sistema atual da maioria das distribuições de usar repositórios de pacotes binários com algum sistema automatizado de download e instalação de pacotes e suas dependências. Engraçado é que ex-usuário de windows têm tanta dificuldade com isso mas não estranha quando ficava catando programas e cracks em redes P2P e sites underground. Até já escrevi artigos sobre como usar repositórios no mandriva, de tanta dúvida que surgia e mau uso (ou não utilização) dos repositórios de pacotes para instalar programas.
A alegação de que produtores de softwares proprietários não conseguiriam fazer pacotes para todas as distribuições é real mas há muito tempo empresas como a Loki já havia resolvido o problema fazendo um instalador "a la Installshield"
http://icculus.org/loki_setup/
Aliás, a empresa que faz o Installshield já chegou a fazer um tal Installshield X multiplataforma
http://www.linuxjournal.com/node/7875
e depois "misteriosamente" deixou de vendê-lo
http://www.macrovision.com/support/1486.htm
como aconteceu com o Kilix da Borland. Pode até ser teoria da consipração, mas toda vez que alguém lança algum software comercial para linux com apelo popular (não científico), misteriosamente é descontinuado pouco tempo depois.
Se pelo menos as principais distribuições linux que usam pacotes .deb e .rpm se unissem num formato de pacotes comum já seria um tremendo avanço para o linux. Tecnicamente não há motivos para não fazer isso.
A alegação de que produtores de softwares proprietários não conseguiriam fazer pacotes para todas as distribuições é real mas há muito tempo empresas como a Loki já havia resolvido o problema fazendo um instalador "a la Installshield"
http://icculus.org/loki_setup/
Aliás, a empresa que faz o Installshield já chegou a fazer um tal Installshield X multiplataforma
http://www.linuxjournal.com/node/7875
e depois "misteriosamente" deixou de vendê-lo
http://www.macrovision.com/support/1486.htm
como aconteceu com o Kilix da Borland. Pode até ser teoria da consipração, mas toda vez que alguém lança algum software comercial para linux com apelo popular (não científico), misteriosamente é descontinuado pouco tempo depois.
Se pelo menos as principais distribuições linux que usam pacotes .deb e .rpm se unissem num formato de pacotes comum já seria um tremendo avanço para o linux. Tecnicamente não há motivos para não fazer isso.
Comentário de Clésio Luiz
18/01/08 13:51 - usuário registrado #13300
É isso aí: "Se pelo menos as principais distribuições linux que usam pacotes .deb e .rpm se unissem num formato de pacotes comum já seria um tremendo avanço para o linux. Tecnicamente não há motivos para não fazer isso."
Não tem, mas eles inventam um assim mesmo :-P
Esse, pra mim, é a última barreira para os "usuários robos" que usam Windows possam mudar para SL sem chiar muito. Tecnicamente falando é mais fácil abrir um Instalador como o do Ubuntu e instalar um programa por lá do que ir catar um programa qualquer na net, baixar, instalar, procurar crack, instalar crack, remover malware depois das buscas :-)
Um sistema unificado de pacotes só traria benefícios. Pena que sempre aparece alguém pra botar terra.
"... e não sabendo que era impossível, ele foi lá e fez."
Não tem, mas eles inventam um assim mesmo :-P
Esse, pra mim, é a última barreira para os "usuários robos" que usam Windows possam mudar para SL sem chiar muito. Tecnicamente falando é mais fácil abrir um Instalador como o do Ubuntu e instalar um programa por lá do que ir catar um programa qualquer na net, baixar, instalar, procurar crack, instalar crack, remover malware depois das buscas :-)
Um sistema unificado de pacotes só traria benefícios. Pena que sempre aparece alguém pra botar terra.
"... e não sabendo que era impossível, ele foi lá e fez."
Comentário de Xis
18/01/08 13:58
Acho que já passou do tempo: Acho que já passou do tempo da comunidade que busca um linux profissional debater esse assunto.
Nenhum fabricante que não queira disponibilizar seu código fonte irá ficar criando pacotes para os vários tipos de distribuições existentes. Depender de desenvolvedores das distribuições para pegar o software, empacotar e distribuir pode também não ser de interesse do fabricante. Se quiserem fazer por conta própria, terão que manter repositórios para SUSE, Fedora, Debian, Ubuntu, Mandriva..
A Kodak tem um programa de fotos que minha mãe gosta de usar. É um .exe. Fico imaginando o dia em que estará disponível um CD-ROM na loja da Kodak e dentro do CD tiver um software em .EXE e outro igual em .RPM, e que este seja instalável em qualquer linux.
Mas, o que vejo é ao invés de pessoas gastarem seu tempo para unificar e fortificar, preferem dividir. Afinal, se não gosto do splash que vem com o GRUB, eu altero e lanço uma distribuição nova, de preferência sem compatibilidade.
Nenhum fabricante que não queira disponibilizar seu código fonte irá ficar criando pacotes para os vários tipos de distribuições existentes. Depender de desenvolvedores das distribuições para pegar o software, empacotar e distribuir pode também não ser de interesse do fabricante. Se quiserem fazer por conta própria, terão que manter repositórios para SUSE, Fedora, Debian, Ubuntu, Mandriva..
A Kodak tem um programa de fotos que minha mãe gosta de usar. É um .exe. Fico imaginando o dia em que estará disponível um CD-ROM na loja da Kodak e dentro do CD tiver um software em .EXE e outro igual em .RPM, e que este seja instalável em qualquer linux.
Mas, o que vejo é ao invés de pessoas gastarem seu tempo para unificar e fortificar, preferem dividir. Afinal, se não gosto do splash que vem com o GRUB, eu altero e lanço uma distribuição nova, de preferência sem compatibilidade.
Comentário de Clésio Luiz
18/01/08 15:10 - usuário registrado #13300
Nem precisa mudar muito: Eu vejo 2 ações que poderiam resolver a maior parte desse problema de múltiplos formatos de pacotes:
1-RPM ou DEB: pra mim tanto faz se algum deles é melhor que o outro. O problema, para o usuário, não é se esse ou aquele formato lida melhor com dependências e resíduos de instalação, mas simplesmente em ter a disposição um maldito pacote pra instalar o programa. Agora mesmo saiu uma versão nova do Yakuake pra KDE4, mas só tem em fonte pra instalar. Se tivesse um .rpm ou .deb pra instalar, eu já estaria usando. Se um dia cai-se um raio na cabeça de Shuttleworth e ele disse-se "vamos de RPM" certamente a guerra acabaria. O projeto Debian ficaria agarrado com o .deb até o fim, mas milhões de usuários ficariam gratos se isso acontece-se um dia. O RPM se tornaria um padrão "de facto" e o usuário comum só ganharia com isso.
2-Um programa instalador: Ao clicar num pacote, o programa abriria, mostraria algumas informações básicas sobre o pacote, você daria apenas um clique pra instalar, daria sua senha e pronto. O programa se encarrega de baixar as dependências e todo mundo fica feliz. O "pobrema" é que toda distro grande tem um programa diferente e nem todos funcionam 100% sem falhas. O do Ubuntu mesmo vive dando erro aqui. Se as distros adotassem um programa padrão pra isso, todo mundo ficaria feliz e fim de papo.
Claro que nem todo mundo que que isso ocorra, pois sempre vai ter alguém que vai ter que trabalhar mais do que os outros se uma mudança ocorrer. E trabalhar mais ninguém quer.
"... e não sabendo que era impossível, ele foi lá e fez."
1-RPM ou DEB: pra mim tanto faz se algum deles é melhor que o outro. O problema, para o usuário, não é se esse ou aquele formato lida melhor com dependências e resíduos de instalação, mas simplesmente em ter a disposição um maldito pacote pra instalar o programa. Agora mesmo saiu uma versão nova do Yakuake pra KDE4, mas só tem em fonte pra instalar. Se tivesse um .rpm ou .deb pra instalar, eu já estaria usando. Se um dia cai-se um raio na cabeça de Shuttleworth e ele disse-se "vamos de RPM" certamente a guerra acabaria. O projeto Debian ficaria agarrado com o .deb até o fim, mas milhões de usuários ficariam gratos se isso acontece-se um dia. O RPM se tornaria um padrão "de facto" e o usuário comum só ganharia com isso.
2-Um programa instalador: Ao clicar num pacote, o programa abriria, mostraria algumas informações básicas sobre o pacote, você daria apenas um clique pra instalar, daria sua senha e pronto. O programa se encarrega de baixar as dependências e todo mundo fica feliz. O "pobrema" é que toda distro grande tem um programa diferente e nem todos funcionam 100% sem falhas. O do Ubuntu mesmo vive dando erro aqui. Se as distros adotassem um programa padrão pra isso, todo mundo ficaria feliz e fim de papo.
Claro que nem todo mundo que que isso ocorra, pois sempre vai ter alguém que vai ter que trabalhar mais do que os outros se uma mudança ocorrer. E trabalhar mais ninguém quer.
"... e não sabendo que era impossível, ele foi lá e fez."
Comentário de jota
18/01/08 15:29
E quem nao tem internet?: Olá,
"O programa se encarrega de baixar as dependências e todo mundo fica feliz..."
Nao pode esquecer de quem nao tem internet. Eu por exemplo só tenho internet no trabalho.
"O programa se encarrega de baixar as dependências e todo mundo fica feliz..."
Nao pode esquecer de quem nao tem internet. Eu por exemplo só tenho internet no trabalho.
Comentário de The Metatron
18/01/08 16:24 - usuário registrado #18237
"Agora mesmo saiu uma: "Agora mesmo saiu uma versão nova do Yakuake pra KDE4, mas só tem em fonte pra instalar. Se tivesse um .rpm ou .deb pra instala"
Ou seja, em fonte, o formato universal e multiplataforma.
E por acaso os teus dedos vão sangrar se você for usar um checkinstall pra criar um .deb ou um .rpm?
Ou seja, em fonte, o formato universal e multiplataforma.
E por acaso os teus dedos vão sangrar se você for usar um checkinstall pra criar um .deb ou um .rpm?
Comentário de Clésio Luiz
18/01/08 18:08 - usuário registrado #13300
Sangrar? Nem dedos eu tenho mais :-P: Brincadeiras à parte, esse é o problema com os fontes. Cada um deles tem algum coisa diferente pra fazer. Lendo os readme dos programas sempre tem uma frescurinha que pode dar errado.
Mas taí uma idéia legal: um programa que, a partir dos fontes, compilaria, resolveria dependências e instalaria pra você. Para isso, bastaria acrescentar um pequeno arquivo de texto junto de cada arquivo .tar.gz, que conteria instruções sobre compilação, dependências, etc. Vou falar com tio Shuttleworth sobre essa idéia :-)
"... e não sabendo que era impossível, ele foi lá e fez."
Mas taí uma idéia legal: um programa que, a partir dos fontes, compilaria, resolveria dependências e instalaria pra você. Para isso, bastaria acrescentar um pequeno arquivo de texto junto de cada arquivo .tar.gz, que conteria instruções sobre compilação, dependências, etc. Vou falar com tio Shuttleworth sobre essa idéia :-)
"... e não sabendo que era impossível, ele foi lá e fez."
Comentário de tenchi
18/01/08 19:08 - usuário registrado #7284
Coloque próteses. Elas aguentam até compilar um kernel ;-): Aí entramos num entrave (nossa, essa foi horrível).
- "Quem sabe quais são os passos necessários para compilar um programa?"
- "Eu sei, eu sei!"
- "Joãozinho"
- "É, ./configure, depois make, depois make install, fessora"
- "Muito bem, Joãozinho. Tirou dez"
O problema é q estes três passos nem sempre funcionam. Os programas que utilizam este método normalmente utilizam as ferramentas autotools (automake, autoconf, autoheader, etc, etc). Tecnicamente é fácil, inclusive, criar um pacote para um programa. Basta executar:
$ make install DESTDIR=/tmp/pacote-2.0.3/
Aí no ditetório /tmp/pacote-2.0.3/ estaria a árvore do pacote, que poderia sem empacotada conforme o sistema que o usuário quiser. O próprio checkinstall faz isso.
Mas acontece que nem todo mundo usa estas ferramentas. Alguns a chamam de autohell. Existem trocentos outros sistemas, como scons, cmake, setup.py, e há desenvolvedores que usam escrevem seus próprios Makefiles. E estes são os que eu mais abomino. Quantas vezes já tive que editar Makefiles para poder criar um pacote...
Há arquivos onde você encontra barbaridades como:
$ cp -rf extra/dados /usr/share/programa/dados
Isso é algo insustentável.
Mas para os programas que instalam no "./configure && make && make install", há ferramentas como o src2pkg, que cria um pacote a partir de um arquivo .tar.(bz2|gz). Testado e aprovado no Slackware (mais informações em http://www.linux.com/feature/121499).
Mas eu prefiro criar meus pacotes manualmente mesmo. Frescura mesmo. Alguns dizem que é falta do que fazer. Mas em sábados chuvosos não há diversão maior.. hauahuah
Aí você deve ver que várias opções podem ser desativadas o ativadas na execução do ./configure. Uma delas é o diretório onde será instalado o programma, com --prefix=/diretório/de/instalação. O padrão normalmente é /usr/local, mas a maioria das distros só aceitam em /usr.
Outras coisas como desabilitar algumas dependências (para que você deve ter o mysql quando quer instalar o amarok? use um --disable-mysql !). Enfim, um método que unificasse tudo seria muito bom, mas há muitas coisas a serem consideradas. A melhor solução, em minha opinião, é a adotada pelos *BSDs e Gentoo. Uma árvore com vários scripts que automatizam a compilação, resolução de dependências de um programa. Acho até que no FreBSD é possível criar um pacote .tgz (ou .tbz?). Digo "Acho" pois estou com alguns problemas com o FreeBSD q impedem q eu o use ;-) (alguém conseguiu instalar o 6.3-RC2 no VirtualBox? Aqui dá um erro interno no VBox no boot...).
Mas este sistema tem um grande problema: A árvore de diretórios dos scripts fica imensa. No gentoo é mais de 400MB! E isso só porque os arquivos são minusculos. Dependendo do sistema de arquivos utilizado, o tamanho ocupado pode aumentar mais ainda.
Mas, enquanto isso, eu vou de Slackware.
---------
Um homem com opinião é sempre um psicopata em potencial.
Aliene-se!
- "Quem sabe quais são os passos necessários para compilar um programa?"
- "Eu sei, eu sei!"
- "Joãozinho"
- "É, ./configure, depois make, depois make install, fessora"
- "Muito bem, Joãozinho. Tirou dez"
O problema é q estes três passos nem sempre funcionam. Os programas que utilizam este método normalmente utilizam as ferramentas autotools (automake, autoconf, autoheader, etc, etc). Tecnicamente é fácil, inclusive, criar um pacote para um programa. Basta executar:
$ make install DESTDIR=/tmp/pacote-2.0.3/
Aí no ditetório /tmp/pacote-2.0.3/ estaria a árvore do pacote, que poderia sem empacotada conforme o sistema que o usuário quiser. O próprio checkinstall faz isso.
Mas acontece que nem todo mundo usa estas ferramentas. Alguns a chamam de autohell. Existem trocentos outros sistemas, como scons, cmake, setup.py, e há desenvolvedores que usam escrevem seus próprios Makefiles. E estes são os que eu mais abomino. Quantas vezes já tive que editar Makefiles para poder criar um pacote...
Há arquivos onde você encontra barbaridades como:
$ cp -rf extra/dados /usr/share/programa/dados
Isso é algo insustentável.
Mas para os programas que instalam no "./configure && make && make install", há ferramentas como o src2pkg, que cria um pacote a partir de um arquivo .tar.(bz2|gz). Testado e aprovado no Slackware (mais informações em http://www.linux.com/feature/121499).
Mas eu prefiro criar meus pacotes manualmente mesmo. Frescura mesmo. Alguns dizem que é falta do que fazer. Mas em sábados chuvosos não há diversão maior.. hauahuah
Aí você deve ver que várias opções podem ser desativadas o ativadas na execução do ./configure. Uma delas é o diretório onde será instalado o programma, com --prefix=/diretório/de/instalação. O padrão normalmente é /usr/local, mas a maioria das distros só aceitam em /usr.
Outras coisas como desabilitar algumas dependências (para que você deve ter o mysql quando quer instalar o amarok? use um --disable-mysql !). Enfim, um método que unificasse tudo seria muito bom, mas há muitas coisas a serem consideradas. A melhor solução, em minha opinião, é a adotada pelos *BSDs e Gentoo. Uma árvore com vários scripts que automatizam a compilação, resolução de dependências de um programa. Acho até que no FreBSD é possível criar um pacote .tgz (ou .tbz?). Digo "Acho" pois estou com alguns problemas com o FreeBSD q impedem q eu o use ;-) (alguém conseguiu instalar o 6.3-RC2 no VirtualBox? Aqui dá um erro interno no VBox no boot...).
Mas este sistema tem um grande problema: A árvore de diretórios dos scripts fica imensa. No gentoo é mais de 400MB! E isso só porque os arquivos são minusculos. Dependendo do sistema de arquivos utilizado, o tamanho ocupado pode aumentar mais ainda.
Mas, enquanto isso, eu vou de Slackware.
---------
Um homem com opinião é sempre um psicopata em potencial.
Aliene-se!
Comentário de puelocesar
18/01/08 19:43 - usuário registrado #5482
Algum de vocês por acaso se: Algum de vocês por acaso se deu o trabalho de clicar no link que eu enviei?
Só por curiosidade, pq eu já acabei de ler uns 5 comentários dizendo que seria legal se existisse uma ferramenta que fizesse o seguinte:
"Ao clicar num pacote, o programa abriria, mostraria algumas informações básicas sobre o pacote, você daria apenas um clique pra instalar, daria sua senha e pronto."
Acontece que o Klik2 que eu falei é exatamente isso..
http://liquidat.wordpress.com/2007/09/06/klik2-a-new-linux-installer-for-the-masses/
www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.
Só por curiosidade, pq eu já acabei de ler uns 5 comentários dizendo que seria legal se existisse uma ferramenta que fizesse o seguinte:
"Ao clicar num pacote, o programa abriria, mostraria algumas informações básicas sobre o pacote, você daria apenas um clique pra instalar, daria sua senha e pronto."
Acontece que o Klik2 que eu falei é exatamente isso..
http://liquidat.wordpress.com/2007/09/06/klik2-a-new-linux-installer-for-the-masses/
www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.
Comentário de tenchi
18/01/08 20:15 - usuário registrado #7284
Ler? Ler é para os fracos. Os fortes impõem: Sim, mas é uma cópia do texto desta notícia.
Ah, e vi o vídeo do klik2. Acho uma boa idéia, mas não é isso que todos os atuais sistemas de gerenciamento de pacotes querem fazer? Clicar, digitar a senha e instalar?
Talvez o problema em "virtualizar" os pacotes seja a questão das dependências, pois cada pacote teria em si tudo o q precisa, comsumindo assim muito mais espaço em disco e memória. Querendo ou não, o "jeitão linux" de fazer as coisas é o q permite maior desempenho e economia de espaço em disco. Mas, ao mesmo tempo, é problemático na questão das dependências.
Ah, e o problema seria convencer todos os desenvolvedores a distribuir os arquivos com os fontes somente nesta forma. É o mesmo que convencer a utilizarem somente - e somente - .deb. Muita gente - inclusive eu - não gostaria q isso acontecesse. Como já foi dito milhares de vezes por muitos aqui, instalar a partir do código fonte é o mais multiplataforma que temos até o momento.
Ou então só usarmos programas feitos em java! Aí é só executar o .jar. Mas, infelizmente java não é lá essas maravilhas.
Acredito q este a inexistência de um padrão real de sistema de pacotes e gerenciamento dos mesmos é só um reflexo de algo comum no software livre: várias ferramentas com a mesma utilidade. É isso q diferencia o (GNU/)Linux dos outros sistemas proprietários: você não tem só um ambiente gráfico; não tem só um interpretador de comandos; não tem só um editor de imagens; não tem só um player de vídeos e músicas. E então porque teríamos só um sistema de pacotes? Aí percebem que não há razão para alguns utilizarem o KDE e outros GNOME. Aí cancelam o GNOME. O KDE é proclamado o ambiente padrão do Linux. Aí pegam o X e o KDE e embutem no kernel. Aí percebem que é melhor colocarem todas informações do sistema num arquivo binário, e não em arquivos texto. Chamam este sistema de "registro". Então decidem que deve haver só uma distribuição Linux. Para garantir isso, fecham o código do sistema.
Pronto, temos um novo Windows!
---------
Um homem com opinião é sempre um psicopata em potencial.
Aliene-se!
Ah, e vi o vídeo do klik2. Acho uma boa idéia, mas não é isso que todos os atuais sistemas de gerenciamento de pacotes querem fazer? Clicar, digitar a senha e instalar?
Talvez o problema em "virtualizar" os pacotes seja a questão das dependências, pois cada pacote teria em si tudo o q precisa, comsumindo assim muito mais espaço em disco e memória. Querendo ou não, o "jeitão linux" de fazer as coisas é o q permite maior desempenho e economia de espaço em disco. Mas, ao mesmo tempo, é problemático na questão das dependências.
Ah, e o problema seria convencer todos os desenvolvedores a distribuir os arquivos com os fontes somente nesta forma. É o mesmo que convencer a utilizarem somente - e somente - .deb. Muita gente - inclusive eu - não gostaria q isso acontecesse. Como já foi dito milhares de vezes por muitos aqui, instalar a partir do código fonte é o mais multiplataforma que temos até o momento.
Ou então só usarmos programas feitos em java! Aí é só executar o .jar. Mas, infelizmente java não é lá essas maravilhas.
Acredito q este a inexistência de um padrão real de sistema de pacotes e gerenciamento dos mesmos é só um reflexo de algo comum no software livre: várias ferramentas com a mesma utilidade. É isso q diferencia o (GNU/)Linux dos outros sistemas proprietários: você não tem só um ambiente gráfico; não tem só um interpretador de comandos; não tem só um editor de imagens; não tem só um player de vídeos e músicas. E então porque teríamos só um sistema de pacotes? Aí percebem que não há razão para alguns utilizarem o KDE e outros GNOME. Aí cancelam o GNOME. O KDE é proclamado o ambiente padrão do Linux. Aí pegam o X e o KDE e embutem no kernel. Aí percebem que é melhor colocarem todas informações do sistema num arquivo binário, e não em arquivos texto. Chamam este sistema de "registro". Então decidem que deve haver só uma distribuição Linux. Para garantir isso, fecham o código do sistema.
Pronto, temos um novo Windows!
---------
Um homem com opinião é sempre um psicopata em potencial.
Aliene-se!
Comentário de puelocesar
18/01/08 21:30 - usuário registrado #5482
Desculpe, mas no Mac OSX é: Desculpe, mas no Mac OSX é assim e funciona MARAVILHOSAMENTE bem.
Você está esquecendo que isto é uma maravilha para desenvolvedores de software. Digamos que eu desenvolvo um software simples e tal, e quero disponibilizá-lo. Bom, hoje eu vou ter que liberar, junto o código, uma série de pacotes para várias distros e várias versões diferentes de distros, como o Opera faz hoje, ou esperar alguns anos até que o aplicativo fique famoso e seja incluído nos repositórios oficiais.
Com o Klik2, eu simplesmente empacoto o software em um arquivo e o deixo disponível no meu site. Simples assim. Assim ele já é compatível com qualquer distro LSB.
A propósito, veja esta apresentação:
http://klik.atekon.de/presentation/klik.html
Ela é bem instrutiva e explica de uma maneira bem humorada o que eu estou tentando passar.
www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.
Você está esquecendo que isto é uma maravilha para desenvolvedores de software. Digamos que eu desenvolvo um software simples e tal, e quero disponibilizá-lo. Bom, hoje eu vou ter que liberar, junto o código, uma série de pacotes para várias distros e várias versões diferentes de distros, como o Opera faz hoje, ou esperar alguns anos até que o aplicativo fique famoso e seja incluído nos repositórios oficiais.
Com o Klik2, eu simplesmente empacoto o software em um arquivo e o deixo disponível no meu site. Simples assim. Assim ele já é compatível com qualquer distro LSB.
A propósito, veja esta apresentação:
http://klik.atekon.de/presentation/klik.html
Ela é bem instrutiva e explica de uma maneira bem humorada o que eu estou tentando passar.
www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.
Comentário de laurocesar
18/01/08 22:33 - usuário registrado #4323
Isso já existe...: Se não me engano Gentoo, Arch, Gobo Linux, Foresight, etc já usam esta idéia que vc disse: Uma "receita" da instalação do pacote que somada ao fonte (c/ endereço de onde baixar, na receita", as dependências são baixadas, os programas são compilados e instalados automaticamente...
Um abraço.
=======================================================
LIBERDADE, IGUALDADE E FRATERNIDADE!
Um abraço.
=======================================================
LIBERDADE, IGUALDADE E FRATERNIDADE!
Comentário de brain
18/01/08 23:24 - usuário registrado #1
ports: Se eu entendi bem o que você está sugerindo, me parece que o sistema de ports dos BSDs faz exatamente isso: mantém uma coleção de makefiles e outros arquivos de configuração, para instalar os softwares diretamente a partir do código-fonte com eles. O Portage, do Gentoo, foi criado com os BSD Ports em mente.
Comentário de laurocesar
18/01/08 23:32 - usuário registrado #4323
É o que quis dizer...: Este tipo de solução a que nosso amigo ali de cima sugeriu, já existe, embora não seja a mais usada entre as distros mais populares. Inclusive o yaourt no arch linux se encarrega de fazer a instalação a partir dos fontes totalmente transparente, basta um "yaourt -Sy nomedopacote" e pronto, pacote baixado com dependências, compilado e instalado. E sei que outras distros e também o FreeBSD (que possui, pelo que ouço dizer, a mais completa ferramenta deste tipo), têm esse recurso.
Um abraço.
=======================================================
LIBERDADE, IGUALDADE E FRATERNIDADE!
Um abraço.
=======================================================
LIBERDADE, IGUALDADE E FRATERNIDADE!
Comentário de mim
19/01/08 11:10 - usuário registrado #18076
Otimo: Otimo!!!!
Mas não pega.. pq tem os fanaticos q gostam de dificuldades...
Mas não pega.. pq tem os fanaticos q gostam de dificuldades...
Comentário de Marcelo Ulianov
19/01/08 12:38 - usuário registrado #2146
Dificuldades?: Sinceramente não vejo dificuldade alguma em digitar : apt-get install "aplicativo". O que deve mudar é a "cabecinha" de quem usa a máquina. No windows é assim, no Mac é assado, mas nos Linux é assim e acabou. Vc pode escolher a distro que melhor se adapta à vc. No Mint Linux existe um repositório on line, aonde vc apenas clica e instala o que vc quiser, sem complicação. É uma variação do apt-get ? É, mas funciona. Para o leigo não existe coisa melhor. Já o usuário avançado, o tal "administrador", esse tem a obrigação de saber compilar, escolher a melhor configuração, pois ganha para isso !
Aqui tem um vídeo que mostra o funcionamento
http://liquidat.wordpress.com/2007/09/06/klik2-a-new-linux-installer-for-the-masses/
Basicamente você baixa um arquivo e roda ele. Mais simples que next-next-finish.
O problema dos gerenciadores de pacote é que usuários vindos do Windows não conseguem entender o quão maravilhosos e práticos eles são e também não são bons para programas que não são famosos o suficiente para entrar em um repositório ou então aplicativos comerciais, portanto eu continuo preferindo usar o meu apt ou pacman para uso geral e adoraria a idéia de poder instalar aplicativos não suportados como por exemplo o Picasa por exemplo apenas dando dois cliques e abrindo. Ou então deixar os meus próprios aplicativos, que dificilmente irão para repositórios, disponíveis para serem instalados assim.
www.darwinawards.com
We salute the improvement of the human genome
by honoring those who remove themselves from it.