Em resumo:: Em resumo:

Ei Mark Shuttleworth, me contrate!

Se foi essa a intenção eu: Se foi essa a intenção eu não sei, mas se o Mark Shuttleworth for realmente esperto eu acho que ele deve aproveitar a oportunidade.

Se correr ...: ... o Google pega, se ficar, o Mark come :)

Se o Mark for realmente: Se o Mark for realmente esperto, ele vai passar longe do Eric.

Mas é claro, chega daquele: Mas é claro, chega daquele chapeu riducilo do fedora, maior insabilidade.
Depois falam que o kurumin é kurumerda, ele vai instala kurumin pra ver? ubuntu acredito que não, pois é outro totalmente insavel, aquelas telas marrom.
Fala serio, fedora já era, só otario usa, como linux como o kurumin não precisa mais de nada nem debian.


Falous

Nem o Eric guenta mais...rsrsrs: Na boa, uso o RH porque sou obrigado, mas eu concordo com o Mr Raymond em alguns pontos.

Uso, por exemplo, o "Red Hat Enterprise Linux AS release 4" que não é tão Enterprise assim. Outras distros, como o "SUSE LINUX Enterprise Server 9" também tem seus podres (como deletar o kernel após a atualização com o yast, sem deixa-lo como opção "old" no boot... perdi alguns máquinas por causa disso.. IHMO, isso não é nada "Enterprise").

Mas voltando ao RH, o yum era realmente lento até o último release do Fedora... melhorou bastante, mas ainda come muita bola se der alguma zica durante um upgrade, por exemplo. Tive sérios problemas de pacotes duplicados no sistemas devido algum crash durante o upgrade (exemplo: ficou no sistema o pacote libpng-1.2.5-182.10 e o libpng-1.2.5-182.9)

Mas o yum não é tão ruim quanto o up2date. Esse sim é um lixo, e é o único disponível no Red Hat AS/ES... não tem search, lento pra caramba, repositórios fracos...

Fora o fato de que essa distro é um desastre para 64bits. Começa na nomeação dos pacotes... que coisa mal feita... affff...

rpm -qa | grep tcp_wrappers
tcp_wrappers-7.6-37.2
tcp_wrappers-7.6-37.2

hã??? pacotes duplicados? dessa vez não... é que um é 32bits e outro é 64... resumindo... eu teria vergonha de usar "enterprise" no nome...

O cara ta certo: Esses problemas com RPM's me mantiveram longe do Linux por um periodo. Eu tentava usar. Na tentativa me via procurando "dependencias" na internet.... Que coisa amadora eh essa? O pessoal nao tem vida? Fica procurando pedacinhos de um app o dia todo?
Entao eu conheci o Debian e o Linux se tornou uma possibilidade no meu desktop.
O engracao que eu... que nao sou engenheiro, notei que os rpms trariam problema pro Linux... Pulei fora do barco desse sistema de instalar software logo no inicio.

Engraçado: Nós lemos o mesmo texto? Porque isso que você escreveu não é nem implícito no texto. Eric Raimond usava Fedora, e não trabalhava para a RedHat, há uma sutil diferença...

Verdade isso sobre o Suse.: Nunca perdi uma instalação do Suse.
Mas nunca gostei da ideia de instalar um kernel e perder o outro, isso é ridiculo.
Fora isso, o Suse é bem estavel, não posso negar.
Para pacotes, o Smart no Suse resolve.
O suse tb, tem a vantagem de ter repositorios bem atualizados.
do KDE/Kdeapps e Gnome e kernel.
Mas nem tudo é perfeito, achei horrivel o gnome da ultima versão.
E nao tem planos rapidos para o LTSP 5.0.

Kernel do SuSE: Eu parei de perder instalações de SUSE's depois que comecei a fazer tar.gz's no /boot antes de rodar o YOU (editado, não é yum)... triste isso, mas é a realidade :)

Imagine que eu tenho milhares de servidores para atualizar, e imagine que sempre uns 20% dá kernel panic pos-yum... é um saco downtime desnecessário devido a uma nhaca dessas, justo no kernel, um pacote assim, digamos, um pouquinho importante...

O up2date tem search sim,: O up2date tem search sim, faz-se com por exemplo:


up2date --show-available | grep pacote


O --show-available mostra todos os pacotes disponíveis para instalação/atualização.

Também, sobre os pacotes de 64 bits, mais uma mancada sua: por padrão o output do rpm não mostra a arquitetura, mas você pode mudar pra qualquer coisa, como por exemplo:


rpm -qa --queryformat %{name}-%{version}-%{release}.%{arch}


Isso vai mostrar a listagem dos pacotes adicionando um .ARCH (i386, ia64, ppc, x86_64, noarch, etc). Pra não ter que ficar fazendo isso toda hora, pode-se configurar o padrao no .rpmrc dentro do diretorio home ou no rpmrc global :)

Desculpe cara, eu concordo em algumas coisas com voce, mas falar que uma distro tem problemas so porque voce nao sabe como fazer ou nem procurou direito a informacao, e' mancada.

Com certeza: E se usar o smart (o melhor, IMO) ou o próprio yum também poderá ver a arquitetura.

Nunca tive problemas sérios com RPM (uso Fedora desde o 2 como sistema secundário), mesmo misturando repositórios não compatíveis entre si (FreshRPMs e Livna). Talvez porque eu configurei tudo certo ou mesmo sorte ;). Mas cada caso é um caso, pois já li reclamações sobre Deb e RPM a respeito de problemas.

Só acho que o Raymond está reclamando de barriga cheia. É o direito dele, fazer o quê, não é?

--
Tudo que postei acima é minha singela opinião. :)

up2date --show-available |:

up2date --show-available | grep pacote

O --show-available mostra todos os pacotes disponíveis para instalação/atualização.

Você acabou de mostrar que o up2date não tem busca :-) (ou que tem mas não sabemos como é, prob. de usabilidade?), o up2date esta apenas cuspindo todos os pacotes disponíveis e o grep fazendo a busca... quando o correto seria o up2date fazer uma busca mais otimizada levando em consideração o conhecimento do up2date sobre o banco de dados de pacotes.

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.or

Putz: Acabei de me lembrar buscando pacotes pela internet tempos atras. Ate que o Ubuntu cruzou meu caminho !
Obrigado Debian !

Olhe, o ubuntu tem o apt que: Olhe, o ubuntu tem o apt que vem do debian, que já foi portado para o conectiva a uns 6 anos atrás. Lembro que o grande marco do conectiva 5, foi o apt!

Então, o ubuntu é muito bom e uso ele, mas há muitas características dele que existem tranqüilamente a mais de 6, 7 anos no debian.
----------------------------------------
http://pihisall.wordpress.com

O rpm não procura: O rpm não procura dependências, o yum faz isso para o rpm.
O dpkg não procura dependências, o apt faz isso para o dpkg.
Acho interessante comparar rpm com dpkg e não rpm com apt (ou yum com dpkg). Não ferramentas complementares :)

--
Gustavo Picoloto
http://cenoura.homelinux.com

Olá: Olá CovardeAnonimo,

Realmente, não fui muito claro. Usando o grep você até consegue fazer uma "busca" nos repositórios, mas eu queria mesmo é algo similar ao 'apt-cache search' que mostra uma descrição sobre o pacote. Agora, o yum até tem search, mas nem o grep resolve aquilo lá :-) Na verdade, logicamente, um whilezinho com awk, cut, sort, egrep e outros afins conseguem filtrar os resultados, mas... peloamor né? É difícil fazer uma busca simples como o apt? Não quero levantar a bandeira do debian, mas o apt, mesmo portado para o rpm é bem superior ao yum/up2date (que só instala, não remove... :/ )

Quanto a arch, eu sei que posso configurar isso ae, inclusive usar o ARCH na hora de remover um pacote sem ter que usar rpm -e --allmatches, mas você deve concordar comigo que é uma solução tosca. Até o SuSE consegue nomear melhor os pacotes 32bits e 64bits para que não seja necessário malabarismos na hora de fazer manutenção em servidores.

O gerenciador de pacotes e a distribuição estão ae para facilitar a nossa vida, não para complicar, penso eu.

Imagine que trabalho com _milhares_ de servidores, e imagine que um mero script pos-install para colocar a máquina no ldap e fazer mais algumas coisinhas ocupou mais de 500 linhas em bash só por conta dessas coisas... sei lá, estou falando mau sim, e ainda acho que existem problemas para resolver. Basta compara-las com um debian da vida, infelizmente, ainda os "enterprises" tem um longo caminho para percorrer...

Abraços

__Acho que o problema está: __Acho que o problema está mais na qualidade dos repositórios...Debian é uma distro focada nas atualizações e até instalações via Internet, enquanto Fedora, Red Hat e Mandriva utilizam mais o sistema de distribuição física dos softwares, vendendo caixas já configuradas para acessar os CDs/DVDs de instalação...

__Como acho os repositórios dessas distros baseadas em RPM sempre limitadissimos, acabo tendo que pegar um pacote na internet com milhares de dependências, e tome tempo sanando dependências cretinas insuportáveis e infinitas, pacotes de 10KB que quando devidamente satisfeitos em sua gula por libs, pulam para 100MB!

__É por isso que acho que distros baseadas em RPM são péssimas para desktop.

Para os nerds ......: ....malditos que querem ficar passando a vida atualizando pacotes, realmente o rpm não é uma boa escolha !!!!

Talvez por isso a Red Hat/Fedora esteja investindo na revitalização do RPM, pois após alguns anos o velhinho já deu mostras de desgaste.....nada como uma nova roupagem.

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Ai e' que voce se engana, o: Ai e' que voce se engana, o conceito original do Unix é criar várias ferramentas especializadas em uma coisa, e então juntar estas ferramentas para um uso comum, como é o que acontece em shell script.

E é isso que aconteceu nesse caso.

Hahaha: Hahaha

Pra o yum, voce pode usar o:

yum list

Exemplo

yum list lib\*

Vai mostrar pacote e sumário. Não precisa usar o yum search, porque ele mostra descrições mais detalhadas. Ponto pra quem lê a manpage :P

Sobre a nomeclatura dos pacotes 32bits e 64bits, não achei nada demais nos seus comentários. Na verdade não entendi, qual a solução tosca? Tendo o .ARCH na extensao nao vejo *nenhum* problema em manusear os pacotes dos servidores.

Outra coisa, em servidor, pra que usar pacotes 32 bits? Usa tudo 64 bits e pronto, não vai ter mais esse problema. Vide servidores Itanium espalhados pelo mundo afora.

Tem que saber usar :)

E sobre o trabalho de ter milhares de servidores por ae pra administrar, é pra isso que serve a Red Hat Network. Registra-se as máquinas lá e pronto, tá tudo feito. Quer fazer tudo de uma vez? Faz via web. Controla tudo, e depois vai tentar fazer isso nas outras distros pra ver como é mais complicado.

Não vi muito incremento no comentário :P

Desktop: O pior é que eu prefiro o Debian justamente pelo ciclo mais longo de lançamentos. Hoje em dia não é mais tão gritante a diferença entre um KDE 3.3 de um 3.4, por exemplo. Então, instalo o Debian, e uso por um bom tempo (somente stable, essa história de usar unstable é pra boi dormir), e tudo num DVD só!

YUM vs APT: Eu, sinceramente, não sei se o gerenciamento de pacotes no formato .DEB é melhor do que os .RPM (dpkg vs rpm). Mas de uma coisa eu tenho certeza absoluta, que a dupla APT/SYNPATIC dá um baile na dupla YUM/YUMEX, ah isso dá!!!

Sem falar na qualidade dos repositórios. No Ubuntu eu simplesmente preciso habilitar dois repositórios que já estão disponíveis no Synaptic, o Multiverse e o Universe. Pronto!

Complicado? Ainda é se comparado com a próxima versão do Ubuntu a ser lançada em ABRIL desse ano. Nessa nova versão, ao clicar sobre uma música mp3, por exemplo, o sistema lhe informará que não há um codec instalado e automaticamente irá lhe oferecer a opção de instalá-lo, automaticamente... Bom, aí creio, ficará bem mais fácil. Nem os nomes dos pacotes será necessário saber... pra usuário doméstico é a melhor solução.

Talves não o seja para usuário power user ou enterprise... mas na boa? Eu até me considero um power user... porém últimamente não estou com muita paciência de ficar sanando dependências, adicionando repositórios, nem compilando nada... preciso de algo que me dê condições de trabalhar... não dá pra perder quase o dia inteiro configurando(pós install) uma distro.


No final, acho que para quem quer uma distro com gerenciamento de pacotes e todas as facilidades provenientes, essa distro é DEBIAN ou UBUNTU. Pra quem não liga pra isso ou quer ter um controle mais efetivo de tudo: SLACKWARE!


Atenciosamente,


----------------------
Rodrigo Messias Barros
UserLinux # 259.148
Brasília-DF

Posso estar enganado , porém...: Em comentarios anteriores fiz referência a "certos grupos" que estão manipulando a opinião pública , ja seja contra ou a favor de diversos produtos (Pratica consagrada a muito tempo). Então, pessoalmente não gosto da politica empresarial da RED HAT (após fatos ocorridos com o Fedora), porém fazer da opinião de um usuário, no importa que seja o grande "mestre", é forçar a barra, e além disso ocupar "web midia" para fazer de uma opinião maior do que ela reflete é no mínimo suspeito.

Quando Nicholas Negroponte reclamou .....: ...que o Linux era inchado demais para o seu notebook para Países terceiromundistas, a Fedora foi lá e trabalhou numa versão mais "light".

Agora que o Eric Raiumundo reclamou do RPM, eles vão trabalhar em cima para melhora-lo.

Não existe nada de errado nisso é apenas a tempestade que precede a bonança (ou bonanza para los hermanos de lingua castelhano/española).

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Bom dia -- continuando o bate papo construtivo ;): Tudo bem pessoa anônima? :)

Então cara... curti a idéia do 'list', nem testei isso aqui ainda mas se você diz que funciona eu acredito. Na verdade, sempre usei o 'search' por achar que ele era o cara que deveria fazer a busca... acho ainda que o search deveria ser usado para procurar algum pacote :p

Quanto a usar o grep na saída do --showall funciona até mesmo pela filosofia *nix, mas é horrível além de ser pouco "didático" (eu procuro por search no manual), uma solução porca para falar a verdade. O que um search "de verdade" deveria fazer é consultar sua base de dados local e mostar o resultado na tela, junto com uma breve descrição do pacote. Isso seria bem mais rápido do que um laço que consulta uma URL e cospe tudo na tela :/

E, por último, o up2date deveria ter pelo menos, (pelo preço que se paga por ele) uma forma de remover pacotes junto com suas dependências e também uma forma de instalar as dependências para compilação de um pacote. Isso faria dele uma ferramenta digna de ser "enterprise". 8)

Sobre a arquitetura 32x64bits... em primeiro lugar eu não me lembro de ter solicitado durante a instalação nenhum pacote 32bits, ainda mais solicitado que ele fosse instalado uma cópia em 32bits e outra em 64bits. Se a própria distro fez isso sei lá porque, era obrigação dela alterar a queryformat default do rpm para que mostrasse a diferença entre os dois pacotes. Os dois aparecem com o nome igual, e dificulta a vida de scripts que removem pacotes desnecessários porque o rpm -e falha ao tentar remover "error: "zlib" specifies multiple packages". Claro que se você especificar 'allmatches' você consegue o efeito desejado, mas a nomeação dos pacotes deveria mostrar por padrão a arquitetura dele, assim como é feito no SUSE por exemplo.

De qualquer forma, achei interessante esse bate-papo, espero que você entenda meu ponto de vista e leve minhas opiniões para frete, no sentido de melhorar um produto que custa muito caro e oferece muito pouco com relação ao mercado atual... Pode me contactar em PVT caso ache necessário (tiagocruz AT forumgdh.net).

Abraços!

Discordo totalmente...: O RPM honestamente nunca me deu problemas, seja no Yum do Fedora ou no URPMI do Mandriva. Eu não gosto dos comentários que elevam os DEBs e os apt da vida (aptitude, apt-get e etc) como se fossem a oitava maravilha do mundo. Ao contrário do Ubuntu, Debian e do Kurumin, eu nunca peguei nenhum pacote RPM quebrado, seja através das ferramentas que citei ou através de sites excelentes e completos como o http://rpm.pbone.net.

Ao contrário, eu lembro quando migrei pra Linux, eu usava Mandrake. Muitos criticavam pra mim dois fatores. Primeiro a distribuição (todos idolatravam o Conectiva, que eu não gostava) e o URPMI. Me diziam mundos e fundos do apt; Achei os pacotes do Conectiva e fiz a instalação do Apt no meu Mandrake. Adicionei os mesmos repositórios e passei a ter dor de cabeça. Removi e as mesmas passaram.

Pensei: Ah sim, é por que o apt é nativo das distribuições baseadas no Debian! Nelas ele funciona adequadamente!!! :) Engano meu novamente. Quando passei a utilizar o apt-get e o aptitude em distribuições baseadas no Debian, aí sim eu vi o que é ter problemas, do tipo:

-> Baixar 200MB de dependências só pra instalar uma libzinha...
-> Ter que atualizar o KDE inteirinho (!) só pra poder instalar o K3B e o Smb4k;
-> Ter um pacote quebrado no sistema (qual?) e misteriosamente o meu X não entrar mais ou o PC/servidor passar a se comportar anormalmente (parar de fazer o DHCP por exemplo);
-> Remover os pacotes instalados que ocasionaram o problema acima e ver que nada é tão ruim que não possa ser piorado;
E o pior, ainda ter que aturar os lunáticos (o melhor termo que encontrei) que colocam o Ubuntu/Debian num pedestal dizendo que os mesmos são Deus na terra.

Eu realmente nunca tive esses problemas no SuSE, no MAndriva nem no Fedora (mais além, nem no Mandrake e no RedHat). Coinscidência? Eu juro que eu não sei, mas problemas como esse me fizeram adotar o Slackware como minha distribuição oficial tanto pros meus desktops quanto pros meus servidores.

Abraços,
Lucas Timm.





----------------

Linux User #405251
(Time completo: Slackware, Solaris, FreeBSD, Microsoft Windows 2000)

E a usabilidade?: E o que acontece com a usabilidade? Prefiro mil vezes uma boa usabilidade do que esses padrões.

Não que eles sejam errados, mas se a ferramenta resolve retornar o resultado de uma pesquisa em 5 linhas eu vou ter que encher o script com grep -A. E se o retorno tiver uma quantidade de linhas variável? sed, awk? Só para saber que pacotes eu tenho disponíveis?

Por que não facilitar?

CentOS: Uso no meu servidor uma distro baseada no RHEL ... o CentOS, e não tenho problemas, mas com Fedora é diferente....uso RH desde o 8, usei o fedora desde que o RH chegou ao pré-10 e daí virou Fedora 1 Arrow....mas existem problemas no yum sim, duplica , trava e as vezes incomoda muito.....mas gosto da distro....se bem que estou pensando em mudar mesmo, mas o servidor continuará com o CentOS que acho excelente..são dois anos rodando perfeitamente.....ele usa o up2date......mas o Linux é isso mesmo...muito dinâmico e dessa forma sempre ocorrem alguns problemas..devemos ter a mente aberta para isso e entender que o nosso linux é um sistema que não para de crescer um segundo...isso é fruto do trabalho das mentes envolvidas no processo, como usuários, dependendo de nosso perfil ou metas, buscamos uma distro estável ou dinâmica...não é o linux o problema...mas nossas escolhas e como lidamos com elas....abraço a todos
Linux User #417.437
machine #325.147
http://estudiolinux.no-ip.info

A opinião do ESR não é confiável. Exemplo:: No "howto" que ele fez de instalação de softwares multimídia no Fedora (até o FC5, suponho que ele vai parar de fazer) ele diz que o Xine "não funciona". Mentira, funciona. Segui o howto para o FC5 (e também para o FC6 com ligeiras variações) e o Xine funciona que é uma beleza.

É para isso que servem os: É para isso que servem os front-ends. Um ótimo exemplo de front-end seria o k3b.

Para o caso dessa discussão, o applet e os programas adicionais do up2date servem muito bem como front-end. Pra usuários que gostam da linha de comando, eu por exemplo, tanto faz você digitar:

apt-cache search string

e

up2date --show-available | grep string

Ou então faz um alias ou um shell-script simples que já procura. Por que será que as pessoas gostam tanto de falar essa tal palavra Usabilidade? Que coisa! :P

E no exemplo aqui so retorna uma linha! Outros casos são outros casos e os frontends sempre podem ser usados/feitos.

Prefiro ter muitas opções a escolher e filtrar meus resultados do que ter apenas uma ou outra opção só por causa dessa tal usabilidade!

Por essas e outras que eu: Por essas e outras que eu uso Gentoo ;)

Questão de travamento,: Questão de travamento, duplicação e outros problemas também ocorriam com o apt. O yum é uma ferramenta ainda nova que vai ter esses problemas que já foram sanados no apt, isso é completamente normal.

velho debate rpm x deb: O formato deb de pacotes tem algumas características a mais que o rpm

http://kitenet.net/~joey/pkg-comp/

mas não têm nada a ver com o que muitos aqui estão alegando e a maioria desses recursos a mais nem são usados na grande maioria das operações de instalação/remoção/atualização de pacotes diariamente. Não gosto do yum e nem o Fedora é a minha distribuição favorita, mas usando o apt4rpm e adicionando os repositórios corretos dá para instalar tudo o que é necessário para usá-lo como um desktop completo.

Quem ainda sofre com rpm-hell hoje em dia em qualquer distribuição baseada em rpm é porque não sabe usar as ferramentas certas da distribuição para instalar pacotes e/ou sai catando na mão rpms de diferentes distribuições ou diferentes versões e tenta instalar na marra. Ferramentas como o yum, urpmi, apt4rpm, aptitude e synaptic (sim, existem versões deles que lidam com rpms) resolvem as dependências, baixam e instalam os pacotes usando o rpm como um manipulador de pacotes de nível mais baixo.

Se está havendo problemas de gerenciamento do PROJETO Fedora, é outra coisa que não tenho conhecimento para responder, mas dizer que a distribuição não presta por usar rpm ou por um detalhe ou outro de natureza técnica acho demais.

------------------------------------------------
Usuário Linux #100343

Concordo com você. Mas para: Concordo com você. Mas para quem não tem saco de compilar e ler não é uma boa distribuição. E o stage 4 está longe de ser algo concreto, por isso o Gen não é uma boa escolha para usuários que só querem entrar na internet e conversar via mensageiro. Claro tem o cd live, mas mesmo assim terão reclamações dele também. Como antigamente se falava não é possível agradar gregos e troianos ao mesmo tempo.

Perfect desktop: O Eric Raymond devia ler esse tutorial

http://www.howtoforge.com/the_perfect_desktop_fedora_core6

para ter um "perfect desktop" com o Fedora...

------------------------------------------------
Usuário Linux #100343

Concordo que o gentoo não: Concordo que o gentoo não serviria apra pessoas que não tem saco de compilar os programas, mas não entendi esse stage4 que se falo.. que eu saiba até agora só existe o stage 1, 2 e 3.. nunca ouvi falar do 4.. sobre o live-cd na minha sincera opinião aquilo não é gentoo, o live-cd (estou falando do instalador grafico) é simplesmente bugadissimo e o instalador pior ainda, acho que tem uma imensa diferença entre um gentoo instalado pelo handbook de um instalado pelo instalador grafico.
Mas o que eu realemnte gosto no gentoo é por ser totalemnte compilado não existe essas histórias de pacotes incopativeis e repositórios "stables, test, unstable" etc
Mas sobre o rpm e deb eu de distros rpm só testei o mandriva 2006, e de deb foi debian, ubuntu e outras.. sinceramente tive bem mais problemas com .deb do que com rpm.. só de lembrar eu querendo remover um k3b da vida e o synaptic querendo remover meu kde inteiro me da calafrios :P

Yum me atende bem:
O que ocorre é que o pessoal novato às vezes se enrola, e os mais experientes em outros formatos não têm paciência de ler o manual (em várias msgs postadas aqui vi claramente que o cara não sabia fazer direito).

Acho que o YUM é equivalente ao APT-GET (e ao SMARTpm), e coisas que ocorrerem com um podem acontecer com o outro. Uso o YUM no Fedora, no CentOS e no RedHat Enterprise.

Precisava padronizar a forma de instalação/atualização de pacotes para facilitar a manutenção, depois de tentar o SMARTpm (não consegui compilar no RHEL por conta das bibliotecas desatualizadas que ele, RHEL, tinha), por isso nem tentei compilar o APT4RPM, achei mais fácil instalar o YUM no RHEL (visto que ele é feito em Python) e ter um repositório local para cada uma destas distribuições usando o CREATEREPO(sitório) para o YUM.

Poderia ter padronizado com o UP2DATE (que existe nas 3 distribuições) mais não entendi como ele funciona, nem como criar um repositório para ele, se alguém souber algum comando nativo, posta aqui. Também não sei criar um repositório para o APT, sei que o APT4RPM pode usar um repositório YUM mas esse tipo de repositório já sei manter, então se alguém souber os comandos para criar/manter um repositório tradicional para APT-GET pode postar.

Quanto aos problemas nas atualizações acho que uma dica é não colocar pacotes .RPM que foram feitos para outras distribuições, não usar "rpm --force" ou "rpm --nodeps", no caso do Fedora, procurar no repositório extras e em outro complementar como Livna ou(-exclusivo) FreshRPMs.

No meu caso, que tenho um repositório local para atualização das máquinas da minha rede, pode acontecer que no mirror feito de madrugada não estejam todos os pacotes que satisfaçam uma determinada atualização. Exemplo hipotético, o pacote freeradius-postgresql depende do pacote freeradius, mas na hora em que meu mirror foi feito a versão deste último ainda não estava disponível, assim de manhã quando checo meu sistema noto que existe uma atualização para o freeradius-postgresql mas eu não vou conseguir atualizar por conta do outro que está faltando e certamente usar coisas como "rpm --force" podem comprometer a estabilidade do sistema.

Aqui vai algumas dicas...

Pesquisar o que está instalado no sistema:

grep -i AlgumNomeOuFragmentoDeNomeDePacote /var/log/rpmpkgs

Se tiver feito muitas atualizações/instalações e queira ter certeza que o arquivo acima está bem atual, basta executar o programa:

/etc/cron.daily/rpm

O que ocorre é que o: O que ocorre é que o pessoal novato às vezes se enrola, e os mais experientes em outros formatos não têm paciência de ler o manual (em várias msgs postadas aqui vi claramente que o cara não sabia fazer direito).

Pois é, um pouco da culpa vai para as próprias distros.
Ainda na época da Conectiva foi desenvolvido o smartpm e apt4rpm, que a maioria das distros mantém nos seus repositórios, mas as distros são meio acomodadas e ao invés de agregar mais recursos nessas ferramentas que já existem, preferem manter suas próprias. Só usuários um pouco mais avançados é que vão preferir instalar e configurar na unha apt4rpm e passar a usar smartpm/synaptic.

Nunca tive problemas DEB, RPM / YUM, APT: Eu comecei usando conectiva, por motivos de hardware novos que o conectiva não reconhecia migrei pro redhat, usei debian tambem por algum tempo, Suse 10.1 e 10.2 , Ubuntu, mas pra trabalho, uso CEntos4.4

Nunca tive problemas com nenhuma ferramenta como yum ou apt, o que muda são alguns detalhes na sintaxe do comando.
E o legal do linux são essas ferramentas, que facilita a instalação , atualização , manutenção etc.. das estações e servidores.

Ao meu ver não diria q uma é melhor q a outra.. eu acho as duas praticamente iguais.

Essa é minha opinião é claro.

Eduardo o stage 4 é o: Eduardo o stage 4 é o estágio onde os pacotes já estão feitos para uma arquitetura, como as outras distros são atualmente. Concordo que o cd live ainda precisa percorrer um longo caminho até chegar a fase madura. E engano seu dizer que não existe fase de testes no Gen, pois a função mask é justamente dividir a parte estável da instável, o famoso _stable e unstable_, mesmo que não sejam divididos em repositórios como é no Debian.

Eu assumo.: Havia tempo que eu não usava o Fedora, tava com os CDs do 6 na minha gaveta sem oportunidade de usá-lo; Então, arranquei o Solaris desse HD e coloquei o FEdora 6 na partição, e fui ver se continuava do jeito que eu usei na ultima vez. E sim, o que mostra a controvérsia da maioria dos comentários aqui feitos.

Sim, o Yum continua lento, mas continua tendo bons pacotes e nenhum quebrado até o presente momento. E sim, o Yum continua lento para operação, porém os downloads continum sendo muito mais rápidos que aqueles mirrors da turma socialista do Debian, aqui está muito rápido o download, demora pra buscar, depois que começa é voado. E sim, o Yum busca. Exemplo? yum search mplayer, a busca logo me entrega dois resultados: MPlayer e MPlayer-Gui. Depois, apenas um yum install mplayer mplayer-gui e a situação está resolvida.

Usem antes de criticar, ou no mínimo, critiquem usando o bom senso.

Abraços,
Lucas Timm




----------------

Linux User #405251
(Time completo: Slackware, Solaris, FreeBSD, Microsoft Windows 2000)