Mini-análise do Gentoo Linux

O link está quebrado!!!
Ok!!

Comigo o link funcionou ...

O dia que eu tiver um tempinho vou instalar o Gentoo. É uma boa pedida para quem gosta de linux maleável e configurado à moda antiga (no braço). Eu acho que vai ter até fãs do Slack se rendendo a ele ...

Eu acho que esse sistema parecido com o ports dos BSDs era uma coisa que faltava, mas eu acho que o ideal seria uma solução híbrida, em que fosse possível também gerar pacotes binários a partir destas compilações; assim, poderíamos compilar na máquina mais rápida e instalar os binários nas outras máquinas para poupar tempo. Alguém sabe se isto é possível no Gentoo ?

Manoel, creio que seja possível sim, desde que você faça o "ebuild" do pacote desejado. O navegador Phoenix é instalado dessa maneira (sem compilação).

[]'z

Contrariando o AngusYoung, não, não é possível. O Ebuilds são apenas scripts interpretados pelo subsistema de pacotes do Gentoo (portage) baseado no ports do BSD no qual indicam o tarball a ser puxado e algumas diretrizes de compilação.

No caso do PHOENIX ele JÀ PUXA EM BINÁRIO, o Ebuild só tem o trabalho de "distribuir" os arquivos no filesystem.

Diego, os ebuilds fazem exatamente isso que você disse, mas nada impede que nos tarballs venham arquivos binários que serão distribuídos no filesystem, e isso não deixa de ser um sistema de instalação.
Desde que, durante a compilação, você não use otimizações específicas de uma determinada plataforma nada impede que você use esses binários em outro micro.

[]'z
Otavio - AngusYoung

P.S.:
1. isso não é um flame :)))
2. Eu não sou um grande conhecedor de Red Hat, mas ... distribuir arquivos (binários ou não) pelo sistema de arquivos .. não é isso que o rpm faz?

Pessoal,

O portage do Gentoo, permite que você crie pacotes com o resultado da compilação de modo a poder instalar somente os binários em outras estações com menor capacidade de processamento.

AngusYoung, não sei se sua pergunta foi nesse estilo, mas o rpm não serve só para distribuir arquivos no filesystem. Isto o (péssimo) pkgtool do Slackware faz. Um formato de pacotes é muito mais que isso, seja rpm, deb, lpp (AIX) ou qualquer outro: ele provê um sistema de dependências, metadados, requerimentos, substitutos, prioridades, scripts de pré-instalação, scripts de pós-instalação, scripts ou programas de configuração (no caso do formato DEB), patches, scripts de construção, dados de arquitetura e possivelmente muito mais coisa.

Hum ... obrigado pelo esclarecimento Claudio ...

Levando em conta o que o r00t disse, aliado ao esclarecimento do Claudio sobre o rpm (e sabendo que o portage faz a boa parte do que foi dito) creio que agora ficou claro, que sim, é possível instalar pacotes binários no Gentoo.

[]'z
Otavio - AngusYoung

Êeeeee Patola.. nunca perde a oportunidade de falar besteira e alfinetar o slack... Quantos anos você tem mesmo? Ouvi dizer que você era um cara adulto, esclarecido.. mas os seus posts mostram o contrário disso... Que coisa não!

E o apt-get faz o q ? faz a mesma coisa... binarios binarios binarios....

Patola morra cara!!!

Já responderam, mas só para completar. O portage (sistema de pacotes do gentoo) faz pacotes binários no "formato" do gentoo: tbz2, que na verdade é o tar.bz2. O GRP é um grupo de pacotes binários prontos para instalar para quem não tem tempo de compilar tudo (ou preguiça).
Além disso, ele faz também pacotes rpm. Pior, é muito simples fazer isso. Dê um emerge -b kde e instale todas as dependências do kde e o próprio kde e pegue os pacotes binários no diretório /usr/portage/packages. Só tem um problema, dê o comando e vá ao cinema. Quando voltar deve estar no meio da compilação. Todo mundo que compila os fontes tem esse problema, não reclamem.

> Isto o (péssimo) pkgtool do Slackware faz.

Porque o Patrick assim o quer, Patola. Se o pessoal de Slack fizesse a cabeca dele ele implementaria dependências e tal em 4 horas (isso depois de encher a cara com a sua própria cerveja)

O pkgtool do Slackware é "primo" do pkgtool dos *BSD e lá eles implementam dependência.

E mais: o pkgtool não é péssimo. Mais uma vez, se você realmente acha isso, vá usar o dos *BSD e vai ver que o problema não está no pkgtool.

O Patrick "implementaria dependencias a hora que quisesse", mas ate hoje nao implementou um sistema operacional decente (ei, ele nao disse que estava querendo usar RPM?). E que nem o viciado que diz que larga a droga a hora que quiser...

Ah, e acorda. Ele nao faz sua propria cerveja ha anos ja.

Novamente, vem o Patola querendo gerar flames.

Esses dias tava ele ai chorando pq n conseguiu
instalar a última versão do gnome pq o rpm tava
com problema.

Ridículo ...

Péssimo e vc. não conseguir instalar o que vc. quer
por causa de zilhões de dependências que o rpm inventa.

Péssimo é não conseguir desinstalar um software sem
ferrar outros. Ou vc. dá um force, ou não desinstala nunca.

Apregoar que um sistema de pacotes é melhor só por causa
de depêndencias é besteira de quem não sabe o que está
falando, aqueles idiotas que ficam catando termos técnicos
aqui e ali.

O Pkgtool instala, remove, atualiza e tem até um utilitário
para vc. gerar os seus próprios pacotes. Isto é um gerenciador
de pacotes na visão de qualquer um, menos na destes manés que
adoram falar mal do slackware.

Oi, Ricardo.

Eu não queria que a discussão embrenhasse por esse assunto mas mantenho minha opinião. O pkgtool é um péssimo utilitário, e se for pra chamá-lo de gerenciador de pacotes então temos que chamar o tar e até o cpio de gerenciador de pacotes também. Como eu disse, a questão não é só dependências: são "dependências, metadados, requerimentos, substitutos, prioridades, scripts de pré-instalação, scripts de pós-instalação, scripts ou programas de configuração (no caso do formato DEB), patches, scripts de construção, dados de arquitetura e possivelmente muito mais coisa".

Pra não ficar na flamewar, no entanto, e mesmo sabendo que no site do gentoo há informações sobre ele (http://www.gentoo.org/doc/en/gentoo-howto.xml), gostaria que usuários do gentoo falassem sobre seu sistema de pacotes, suas vantagens e desvantagens (vamos ser honestos, ok?), como é seu uso cotidiano e como ele pode ser utilizado para instalações em larga escala, se é que isso se aplica.

A propósito, Ricardo, só para lembrar: não troque a solução pelo problema. As dependências são uma característica de um sistema de pacotes que existem exatamente pra te dizer que pra rodar direito (ou simplesmente pra rodar), um determinado pacote precisa daquele outro pacote. Elas são a solução e não o problema. Não adianta você tentar executar o konqueror sem as kdelibs, por exemplo, que ele não vai ser executado... Tente imaginar um fosso com jacarés: você tem a opção de colocar ou não uma placa dizendo que ali tem jacarés. Se não tiver a placa, a maioria das pessoas só perceberá isso tarde demais.

É lógico que se você faz questão, mesmo, os sistemas de pacotes costumam ter todos os flags para que você instale um pacote como no slackware, sem que ele olhe para as dependências. como o --force e --nodeps do rpm. É como ler a placa dos jacarés e mesmo assim pular no fosso: pelo menos você foi avisado!

O tar ou cpio, instala, desinstala ou atualiza um software ? Agora vc. chutou o pau da barraca.

Também mantenho o que eu disse sobre o pkgtool ser um bom sistema de pacotes e explico o pq abaixo.

Dependencias são a solução ? Depende de como é implentado isso. O rpm ( não vou falar do deb, pq não conheço ) amarra softwares a outros. Se vc. tiver que remover uma lib para colocar outra vai ter q sair removendo vários softwares que talvez nem fosse necessário. Apenas por imposição do rpm.

Ex. KDE 3.1 precisa da nova QT ( n lembro agora qual a versão ). Se eu fosse com rpm retirar a QT antiga para por a nova ( retirar e colocar, não quero fazer update ). Ia ser uma batalha, pq ele ia ficar falando fulano usa, beltrano tb., etc...

No slack, removi a qt antiga, instalei a nova, tudo via pkgtool. Se amanhã algum outro programa reclamar ( nenhum reclamou até agora ) atualizo o programa.

Esta é a simplicidade que o slack oferece. Não estou desmerecendo o rpm ou outros. só estou dizendo q o pkgtool tem sim suas vantagens.

Mesmo assim, Ricardo. Como eu disse, rpm --nodeps --force faz o que você quer, no caso do rpm. Cada sistema de pacotes tem seu jeito de pular as dependências.

" Mesmo assim, Ricardo. Como eu disse, rpm --nodeps --force faz o que você quer, no caso do rpm. Cada sistema de pacotes tem seu jeito de pular as dependências. "

Sim, mas faça isso e o rpm vai ficar perdido na hora de mexer com alguma programa onde vc. usou --nodeps --force

Então vc. cai na seguinte situação : Ou não I/A/R o software por causa das multiplas depêndencias. Ou I/A/R com --nodeps --force e compromete o sistema, ou seja, vc. fica amarrado ao sistema de pacotes. ( I-nstala, A-tualiza, R-emove )

E nem vou falar sobre dependências ciclícas, que ocorrem de vez enqto. ( A precisa de B para instalar e B precisa de A ).

Outra coisa, não sei como um camarada meu ( não sei exatamente como ) instalou dois pacotes rpm com o mesmo nome. Agora n consegue retirar nenhum pq. o rpm não sabe qual dos dois ele quer retirar ( tem o mesmo nome ).

Dependências cíclicas (que tem sua razão de existir também) se resolvem instalando os pacotes A e B juntos.

Quando você usa --force --nodeps você continua podendo usar o rpm normalmente. Só que utilitários de mais alto nível que usem a base de dados dos pacotes como o apt irão reclamar. Nada que seja realmente 'showstopper'.

Quanto ao seu camarada, peça pra ele usar rpm -ev --allmatches que aí ele remove todos os rpms que tenham aquele nome. Se necessário pode ser que você tenha que usar --nodeps ou --force. O rpm tem flags pra todos os casos... =)

"Quando você usa --force --nodeps você continua podendo usar o rpm normalmente."

Discordo, pq. já tive de resolver vários problemas por conta disso. Funciona normalmente até que vc. tenha que ( como eu disse ) mexer naqueles que vc. usou --nodeps --force.

Não sei se ele já resolveu, mas passarei a dica. Obrigado.

Bom, não vou ficar esticando este assunto. Vc. não me convenceu que o pkgtool é ruim, eu não te convenci que é bom. O Inferno vai congelar e ainda estaremos aqui refutando argumentos um do outro.

> Dependências cíclicas (que tem sua razão de existir também)

Existe? Eu não consigo pensar em nenhum caso em que haja razão para existir dependência cíclica.

Em todo caso, voltando à programacão normal...

Voltando ao Gentoo...

O meu emprego exige o uso de FreeBSD (devo ser um dos poucos que usam FreeBSD no trabalho e Linux em casa :). O ports do FreeBSD, como todo mundo sabe, é a inspiracão do portage do Gentoo.

O ports system é um excelente sistema para ter pacotes otimizados e/ou com necessidades especiais, visto que você pode compilá-los definindo variáveis, diretamente no Makefile ou na linha do make. Claro, é necessário manter a sua árvore do ports atualizada (cvsup é seu amigo); como a árvore do ports são apenas os patches para FreeBSD (os programas são baixados diretamente dos seus sites), o custo em termos de largura de banda não é tão grande.

Atencão que o ports+pkg_* NÃO é um updater (sim, você pode acabar em uma situacão com trocentas versões do mesmo pacote e o sistema não vai estar nem aí); no entanto, existe um programa chamado portupgrade (sysutils/portupgrade) que faz esse trabalho e, honestamente, cvsup+ports+portupgrade+pkg_* te dá uma flexibilidade que o apt não te dá, pelo menos enquanto o apt-build não se estabilizar. (Lembrem-se que o pkg_add do FreeBSD é "esperto" e pode baixar os pacotes diretamente da rede e baixar também suas dependências).

Não testei o Gentoo (não tenho banda pra isso aqui em casa), mas se o pessoal não fez nenhuma burrada homérica o portage tem um excelente pedigree.

Por coindidência, uso linux no trampo e FreeBSD em casa.. hehehe... alias, depois que eu vi o ports fiquei com uma vontade de ve-lo funcionando no slack... Já ouvi falar que da pra "portar" o ports do debian pro slack.. seria interessante um ports+checkinstall+pkgtool.. Três ÓTIMAS (a não ser na opinião do sabichão PATOla) ferramentas que trabalhariam muito bem juntas.. ainda vou tentar esse jogo...