É uma pena que as grandes di: É uma pena que as grandes distros não quererem adotar o Autopakage (mesmo que seja uma segunda opção). Preferem ficar reinventando a roda, com novos instaladores que no fundo tem o mesmo objetivo.

Nao sei ate' que ponto isso e' uma vantagem.: Nao sei ate' que ponto isso e' uma vantagem. Instaladores binarios despericao espaco, criam problemas de compatibilidade, duplicam codigo, etc. Tem gente que e' acostumada demais com o Windows e **ACHA** que um install.exe duplicando bibliotecas do sistema (para evitar dependencias), duplicando codigo de instalacao (para portabilidade), etc. e' vantajoso.

Pessoal, vamos popularizar a LSB e dar uma forcinha pro RPM!

Não sei qual o sentido dessa: Não sei qual o sentido dessa alegação de que instaladores binários criam problemas de compatibilidade, poderia ser mais claro?

Quanto a duplicação de código, ela pode ocorrer ou não, depende que versão da biblioteca você tem instalado. Considerando que quem empacota/desenvolve o programa não tem nenhum controle sobre que versões o usuário mantém instaladas, não vejo nenhuma solução melhor do que empacotar a aplicação junto com as bibliotecas não-padrão, ou tê-las em pacotes separados, dependendo apenas do LSB. Agora mesmo instalei o Gimpshop(versão hackeada do Gimp que põem ordem na tradicional desorganização de janelas do mesmo) e ele ficou reclamando que o GTK+2 que tenho é velho(mesmo que a diferença seja apenas o terceiro número de versão!) e pede para atualizar... Tenha dó, né?

Essa abordagem não deve ser somente Windows. Talvez outros sistemas façam uso disto. Tem gente que parece que ficou traumatizada com o monopólio...

Popularizar o LSB não vai resolver o problema das dependências, vai apenas resolver o problema de base comum.

*** Off Topic ***: "Gimpshop(versão hackeada do Gimp que põem ordem na tradicional desorganização de janelas do mesmo)"

Desculpa, mas de que desorganização vc tá falando ????!!! Se é a respeito da inteface SDI, desculpe te desapontar, mas o Gimpshop não muda nada neste sentido em relação ao Gimp.

Eu falei desorganizada no sen: Eu falei desorganizada no sentido de que a aplicação não fornece uma forma de organizar as janelas sem ter que clicar em cada uma quando se alterna a aplicação para outra. Seria melhor que simplesmente se clicasse na janela principal e trouxesse as outras janelas abertas automaticamente.

Esse binário que ele gera na: Esse binário que ele gera nao desperdiça espaço nenhum, ele apenas cria um cabecalho com os dados que o autopackage usa pra instalar.
e falando em padrão o autopackage segue o FHS, que é o que todas as distros deveriam seguir

Soluções mágicas x engenharia de pacotes: Eu vejo que, com mentalidade de Windows, as pessoas têm essa noção de que fazer "pacotes" de programas é algo fácil ou trivial.

Está longe de ser assim. Um software é dependente de muitas coisas e, instalado no sistema, susceptível a muitas outras. Um bom formato de pacotes especifica arquivos de documentação, de configuração (que podem ser modificados pelo usuário e podem exigir tratamento especial em updates, mudando formatos), conflitos com outros softwares, atualização de menus dos diversos gerentes de janelas, possibilidades de alternativas, etc. Não é, portanto, algo para o qual possamos simplesmente rodar um programinha "mágico" que faça um pacote genérico. É algo que exige uma engenharia específica e um estudo bem profundo do modo de atuar do programa. Eu não gosto da denominação 'debian developers' (desenvolvedores do debian) para o pessoal que cria pacotes .deb oficiais para essa distribuição, mas qualquer um que tenha estudado bem os formatos de pacote tem que concordar que o trabalho deles é bem profundo e razoavelmente intelectual. A mesma coisa para o pessoal da Conectiva, que cria os melhores RPMs de todas as distribuições.

Programas como autopackage ou checkinstall (são diferentes, ok, mas procuram se popularizar ambos sob a efígie da "facilidade de fazer um pacote genérico") ajudam quando temos algo não propriamente empacotado para nossa distribuição. Mas, francamente, quando temos, é uma solução muito mais pobre.

Espero que a popularização de formas como o autopackage não cause o fenômeno do empobrecimento dos pacotes. Afinal, se você com ele faz pacotes que possam funcionar em todas as distribuições, você perde especificidade - tanto recursos dos formatos de pacotes próprios (deb, rpm, etc.) - quanto análises específicas da distribuição em questão.

--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Ok, ainda não li o artigo. : Ok, ainda não li o artigo.
Porém vou dar meu comentário a respeito de empacotamento, as distros estão perdendo tempo na pluracidade de forma/tipo de empacotamento : tgz, rpm, deb,...
Na minha opnião devia-se escolher uma e usar, pior ou melhor não importa, a questão é padronizar. Até o formato tar/zip descomprimindo os binários diretamente no /opt serve (jeito porco), mas que pelo menos adotem um formato para todas, oras.
Sei que o modelo opensource se adapta bem a qualquer necessidade, porém a industra de hardware/software proprietário não conseguem conviver com tanta pluracidade. Um dia isso vai ter que acabar se o linux quiser se popularizar no desktop.

Tudo bem, mas...: Tudo bem, hamacker, mas pra quem você está falando isso? Pra quem dirige seu "bug report"?

Pense bem, a comunidade desenvolvedora de software livre é um enorme balaio de gatos. Empresas e indivíduos de diversos tipos, opiniões e temperamentos. Não existe autoridade nesse mundo.

Suponhamos que você sensibilize o Linus. Ok, ele é um grande ídolo no mundo. Ou mesmo o Richard Stallman. Daí ele vai passar a defender essa bandeira - "somente um tipo de pacote" - e vai ter que especificar: digamos, RPM (o formato adotado na LSB).

Ele vai defender a bandeira - e quem a vai seguir? Certamente o pessoal do Debian vai achar um ultraje e vai continuar tentando aumentar o alcance de sua distribuição e de seu formato. Sem contar o Kurumin, Ubuntu, Progeny etc... duvido que concordem e mudem a base da distribuição.

Este é o mundo do software livre. Não existe uma central a que se relatar. Você pode reclamar, pode falar o que quiser, mas daí a conseguir convencer unanimamente todo mundo a seguir isso...

Minha opinião: a pluralidade do software livre não tem que acabar para o GNU/Linux prosperar no desktop. Existem outros caminhos que não a massificação/uniformidade total. Claro, para uma empresa/corporação, a uniformidade é muito importante, tanto para eficiência quanto outros fatores e não discordo de jeito nenhum disso e ainda reforço - um padrão apenas para as máquinas de suas dependências. Mas as dependências da corporação são um contexto diferente do software no mundo todo.
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Meu comentário é direcionad: Meu comentário é direcionado a todos que querem aparecer com uma solução mágica de empacotamento. É mais uma revolta do que um comentário.
Desde que eu começei com o Linux, fico ouvindo falar de gerenciamento de pacotes, simplificações, e dezenas de soluções ficam pipocando : checkinstall, autopackage, smart,... e simplesmente nunca pára.

Não sou contra a plularidade, mas tem que coisas que as distros grandes tem que fixar parametros comuns e parar com a guerrinha do "o meu é maior que o seu". Achei que a LSB tinha chegado a um resultado quando o formato .rpm foi escolhido. Não que .rpm fosse melhor que outros, mas é necessário começar por algum lugar.

Ultimamente a unica forma de checar dependencias de forma segura tem sido o uso do which [`programa`] que pouca vergonha!

Autopackage: Na minha opinião o autopackage no estado que está não soluciona o problema.

Ele não se integra com as ferramentas nativas de gerenciamento de pacotes da distribuição. Assim, ele pode sobrescrever um arquivo contido em um pacote rpm ou dpkg por exemplo.

O ideal seria ele analisar o sistema e criar um pacote rpm, deb ou tgz contendo o programa e todas dependências que fossem necessárias acrescentar. Eu ainda sou mais o checkinstall. Mas eu acho que isso poderá acontecer nas versões futuras pelo que li rapidamente no site.

Além do mais, não achei nada fácil criar a especificação do pacote para o autopackage. É tão ou mais compricado do que criar um arquivo .spec para criar um rpm.

No entanto, o autopackage pode ser útil para distribuição de programas comerciais.

Essa idéia de instalador é muito windows para o meu gosto. É uma abordagem inferior do windows que não devemos copiar. Gerenciamento de pacotes rpm ou deb são muito superiores.

Instalador: Manoel,
Instalador pode ser "muito windows", mas é bem mais simples do que ter que lidar com um rpm que reclama de coisas banais. Se vou instalar um programa que dependa da gtk2 e ela está instalada com um pacote que a nomeie gtk+2, é problema certo. Não lido muito com .deb, mas que o sistema de pacotes é um parto, isso é. Francamente, no OS X as coisas são feitas de forma simples e prática. Como usuário, não me importo se essa ou aquela solução é superior tecnicamente. O que me importa é que resolva meu problema com rapidez e eficiência.
Um exemplo de como as coisas são:
Visite o site http://www.ifolder.com/download.html
Agora, tente instalar o ifolder em cada um dos sistemas operacionais (linux, windows e Mac).
Você terá que instalar o mono instalado (ou o .NET). No Windows ele baixa e instala automaticamente. No Mac OS X você baixa um único arquivo .dmg e o resto é mamão com mel. Boa sorte pra fazer a mesma coisa no linux. São vários pacotes rpm, dezenas de softwares reclamarão de nomes arquivos/pacotes que você *tem instalados*, mas com nomes diferentes...
Em qual o procedimento é mais simples? Usuário não quer nem saber como foi feito esse ou aquele aplicativo, quer é que funcione de forma simples, prática e intuitiva.
Uma coisa muito comum hoje é a utilização de vpn. Peça a um usuário mediano para instalar um cliente vpn qualquer no linux e veja o quanto o mesmo terá dificuldades para fazê-lo.
Espero que as coisas mudem nessa área, senão o linux não vai passar dos 4% de desktop e será utilizado apenas por geeks e uns poucos corajosos.

Boa sorte pra fazer a mesma c: Boa sorte pra fazer a mesma coisa no linux. São vários pacotes rpm, dezenas de softwares reclamarão de nomes arquivos/pacotes que você *tem instalados*, mas com nomes diferentes...

Joerlei, você está misturando os motivos. Sua frase tem duas asserções distintas:
- o iFolder é difícil de ser instalado por rpm.
- a culpa disso é de o formato rpm ser ruim, pelo menos comparado com os sistemas de instalação Windows e Mac.

Com a primeira eu posso concordar, mas você não demonstrou a segunda. O fato é que existe uma série de outras razões possíveis: um empacotamento malfeito (seria como querer culpar o gcc por um programa com código ruim), o pacote ter sido feito para uma distribuição que não a em que está sendo instalada, uma árvore de dependências não-integrada à distribuição...

Tente sempre ver pelo outro lado da questão. Se eles deixassem o iFolder para download para o GNU/Linux do mesmo modo que deixam para o Mac ou Windows, seria melhor? Certamente que não, afinal, se você já tem o mono, as bibliotecas gnome e todas essas coisas instaladas, é muito melhor reaproveitá-las do que tê-las estaticamente no executável. No Windows e Mac faz sentido isso porque não é comum ter GTK+2 e Mono instalados, ora.

Isso evidencia outra coisa em sua afirmação: é uma generalização precipitada e ela apresenta omissão de dados, por apresentar as coisas de forma tão simplificada.

Em qual o procedimento é mais simples? Usuário não quer nem saber como foi feito esse ou aquele aplicativo, quer é que funcione de forma simples, prática e intuitiva.

Você deve sempre ter em conta o contexto ideal para as coisas, isto é, os desenvolvedores de software fazendo as coisas certas. Pode ser difícil encontrar hoje em dia coisas assim - programas comerciais integrados à árvore da distribuição. Mas isso é em parte causado pelas pessoas que insistem em que esse não é um sistema de instalação bom, fazendo o pessoal que faz a instalação desses programas tentar outras soluções. Pra sair desse círculo vicioso, temos que dar algum "crédito", digamos, pro apt ou pro yum, que instalam muito bem pacotes de software comuns do repositório da distribuição.

Aliás, na verdade, nem o pessoal do autopackage discorda disso. Você viu o FAQ deles? Tá certo que isso não é argumento, mas coloquemos em perpectiva, leia isso.

Espero que as coisas mudem nessa área, senão o linux não vai passar dos 4% de desktop e será utilizado apenas por geeks e uns poucos corajosos.

Desculpe, mas não resisto. Acabo de colocar um guia de falácias no meu sítio e não resisto a destacar mais uma: apelo às conseqüências =)
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Nem rpm nem deb nem tgz: Gente, o fato é que, tanto o rpm, o deb e o tgz (para slackware) são falhos. Os programas se atêm ao nome das dependências que estão nos pacotes. Por exemplo, se tenho o gtk2+ instalado, na instalação de um rpm que solicita o gtk, gerará erro de dependência se o gtk tiver o nome de gtk2-+. Pode ser até o mesmo pacote, mas dará erro. Aí, pimba para quem fez o bendito empacotamento do programa que se está querendo instalar. Nesse ponto, sou a favor sim de um programa estilo Windows. Porque ficar jogando pedras no que funciona legal? Pode-se aperfeiçoar os installshield da vida, melhorando a forma de instalação. E acho que é isso que o pessoal do autopackage está tentando fazer. Vai dizer que alguém tem dificuldade de se instalar um programa do tipo Open Office?

Ricardo Rabelo Mota
Site Católico Nossa Senhora Rosa Mística
http://www.rosamistica.org

Falso dilema: Porque eu não disse que não existia um problema, apenas não concordei com as colocações do Joerlei; e você colocou um falso dilema, pois não existem só as soluções "continuar com o rpm como está" (ou deb, ou tgz etc.) ou "usar a solução windows do installshield". E, de fato, a solução que eu acharia mais razoável seria uma camada como o smart da conectiva, que, além das funções que desempenha hoje, "traduzisse" nomes de pacotes se necessário.

A propósito, a suposta "falha" do rpm, tgz e deb não é deles, e sim de algo externa ao formato - política de nomeamento de pacotes. Esse argumento é uma forma de distorção de fatos. ;) E sim, estou sendo mala com esse linkzinhos irritantes, considere um treino.
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Não sei porque tanto barulho: Não sei porque tanto barulho por causa de sistema de pacotes.... Todos sabem que distribuicoes que jah tem seu sistema de pacote seja rpm,deb,tgz ou o ca#$%lho a 4 nao vao mudar o sistema de pacotes tao cedo por mais que ele seja perfeito, na melhor das hipoteses vai alterar o deles para interagir com os outros. Eu fiz esse artigo para pessoas que como eu tenham feito sua distro do zero possam organizar melhor os pacotes compilados sem depender de qq outro sistema de pacote, ateh pq com isso fica facil gerar atualizacoes,recompilações,etc.

Patola, : Patola,
Acontece que o iFolder pra Windows e Mac OS X também não trazem o mono compilado estaticamente. Tanto para OS X quanto para Linux, você tem que instalar o mono. O que mencionei é que, naqueles sistemas, a instalação, tanto do Mono quanto do iFolder, é muito mais simples.
E, para usuário final, seja ele iniciante ou experiente, que quer apenas utilizar determinada ferramenta, gerenciadores de pacotes não são parte da solução, mas parte do problema. O difícil é geek/nerd entender isso. Lembre-se, usuários não se interessam por código fonte, se o software é livre, etc. Questões políticas/filosóficas não interessam. O que interessa é se determinada ferramenta soluciona determinado problema de forma simples, prática, direta e com baixo custo.
Entendo também que o que eu e a grande maioria dos usuários queremos no linux talvez jamais seja possível. Infelizmente, é assim que as coisas funcionam (ou não). E, infelizmente também, não há nenhuma empresa com poder/interesse suficiente para mudar esse quadro. É uma área arriscada e os benefícios não compensam tais riscos. Também é lamentável que nos dias de hoje não tenhamos competição no mercado de desktops.

"Instaladores binarios desper: "Instaladores binarios despericao espaco, criam problemas de compatibilidade, duplicam codigo"

Se, mas só se, instalar os binarios duplicados na pasta home/user e não sobre escrever os binarios originais nas pastas /bin /usr/ etc não vejo problema. O projeto gnu tem uma coisa parecida que cria um diretorio / virtual dentro de uma pasta (cheio de symlinks) que permite instalar software sem SUJAR o sistema da maneira que o Windows faz.

Para viabilizar o linux no desktop domestico (quer dizer na casa das pessoas comuns) alguma solução há de se criar. APT ou Emerge são grandes, mas necessitam de conexão rapida à Internet, coisa que a maioria não tem. Por outro lado um CD de revista sai bem mais barato.

Isso não altera nada: Acontece que o iFolder pra Windows e Mac OS X também não trazem o mono compilado estaticamente. Tanto para OS X quanto para Linux, você tem que instalar o mono.

Em outras palavras, mostra-se mais ainda a ineficiência dos outros sistemas, porque o que você tem nesse caso? DEPENDÊNCIAS. Que no GNU/Linux funcionam assim, idealmente: você diz o software e este software - e todas as suas dependências - são instaladas pra ti automaticamente. No Windows e Mac, como não há algoritmo embutido de resolução de dependências (pelo menos para ferramentas/aplicações externas - coisa que o Windows Update e a instalação do Mac OS X não tratam), você tem que pegar uma por uma...

Pode não ser muito doloroso nesse caso do iFolder - somente UMA dependência - mas o será, certamente, para algo com utilização de código de muitas fontes diferentes (como o Evolution).

Agora, me parece que você não "pegou" as coisas que ressaltei, Joerlei. Falando sério, você não está argumentando: está jogando com as palavras. Está lamentando e ameaçando, se colocando no lugar da maioria, colocando palavras na boca de outros. Vou só ressaltar alguns trechinhos mais aqui:

E, para usuário final, seja ele iniciante ou experiente, que quer apenas utilizar determinada ferramenta, gerenciadores de pacotes não são parte da solução, mas parte do problema.

O que é usuário final? Conheço poucas definições mais vagas e controversas no mundo da computação do que essa. Por exemplo, na minha própria definição de "usuário final experiente", este sabe se virar perfeitamente bem com pacotes, tanto que é experiente. Você na verdade criou uma definição sua, restrita, apenas para defender essa sua tese. Posso dizer que você usou a falácia da definição pouco clara ou ainda que usou uma definição circular, pois na prática definiu como "usuário final" o sujeito que não sabe se virar com pacotes. Ah! E claro, mesmo se aceitarmos sua definição de usuário final, temos o problema do apelo à autoridade para opinar sobre algo controverso, além do que é uma autoridade anônima.

Argumentar não funciona assim, cara. Se quer defender uma opinião, use de argumentos lógicos. Falácias vazam de todo o seu discurso: "gerenciadores de pacotes não são parte da solução, mas parte do problema." - você não sustentou com argumentos e fez uma petição de princípio; "O difícil é geek/nerd entender isso." - você dá aqui um belo exemplo de uma conhecida falácia Ad Hominem, o apelo aos preconceitos. "Entendo também que o que eu e a grande maioria dos usuários queremos no linux talvez jamais seja possível." - aqui dá outro exemplo de Ad Hominem, essa chamada de apelo ao povo. E daí por diante... sua argumentação é completamente vazia, fraca. É exatamente o tipo de coisa para o qual fiz o meu sítio: eliminar esse tipo de FUD. Não existe somente a sua solução de instalador à la Windows, o paradigma de pacotes não é ruim ou não-amigável - apenas ainda "não completamente compreendido" pela mentalidade dominante Windows - e você faz um discurso pobre se insiste em usar essas técnicas de persuasão sem conteúdo.
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

OFF TOPIC: Patola,
TODOS os seus "linkzinhos irritantes" estão mandando para

"Access denied
Você não está autorizado a acessar esta página"

É esta a intenção mesmo? Eu, sem estar cadastrado, gostaria de visualizar alguns dos temas tratados nos links.

Dá para fazer?

Valeuz.

Bug consertado!: Valeu pelo relato de bug, renato. Localizei no código e consertei. Obrigado mesmo!

--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!