Fórum Ubuntu Linux - PT
Espaço da Comunidade => Café com Ubuntu => Tópico iniciado por: JeffersonX em 29 de Dezembro de 2007, 11:51
-
Ao instalar programas no Linux temos diversas maneiras. Mas hoje é cada vez mais forte o uso de pacotes. Antigamente a compilação era muito usada. Mas com a necessidade de se instalar, administrar, remover e atualizar rapidamente fica difícil administrar o sistema e manter fontes em disco, já que para remover é necessário ter os arquivos para o famoso make uninstall.
Com esse cenário o gerenciamento de pacotes tornou cada vez mais utilizado e hoje está presente nas distribuições Linux.
Porém não há um padrão único e padrão adotado pelas distribuições. O RPM já foi bem grande, porém com o crescimento do uso do Debian, o padrão DEB juntamente com "salvador da pátria" APT-GET explodiu se tornando muito utilizado. Ainda há um terceiro padrão utilizado, o TGZ do Slackware. Esses são os 3 mais utilizados hoje.
Mas quais as vantagens e desvantagens de cada um? Porque o DEB está se tornando cada vez mais forte e utilizado? Porque RPM e DEB Não se tornam apenas um? Essa é a pergunta que a comunidade Linux faz todos dias.
RPM
O Red Hat Package Manager foi o padrão criado pela Red Hat e inclusive foi portado para outros sistemas como Netware e AIX. Ele consiste em um banco de dados com todas as informações dos pacotes instalados no sistema como versão, tamanho, dependências, pacotes providos, etc.
Como o Red Hat originou várias distribuições derivadas, como Mandriva, Fedora e outras, o seu uso é muito grande entre as distribuições Linux. Porém possui um problema grave: uma ferramenta avançada e, principalmente padronizada para gerenciar o banco de dados e resolver dependências.
Cada distribuição adota seu padrão. Algumas usam o YUM, outras URPMI, o Suse o YAST, outras APT-RPM... Nada de padrão. O funcionamento é bem parecido entre elas, mas o padrão poderia ajudar mais a desenvolver a ferramenta do que apenas formas paralelas de uso. O YUM trabalha muito bem, porém tem um problema grave de lentidão. Ao menos é o que se nota com o Fedora 8 e o Pirut (uma ferramenta um pouco carente de opções, diga-se de passagem), onde a verificação de dependências é um pouco lenta e o serviço Yum Update pode causar alguns travamentos do banco de dados. O URPMI da Mandriva funciona muito bem e rápido. Poderia ser adotado pelas distribuições RPM. Seu funcionamento com o Centro de Controle do Mandriva também é muito bom.
O Suse com o YAST também faz muita coisa boa e o gerenciamento parece um pouco o Synaptic. O APT-RPM está caindo cada vez mais em esquecimento depois da fusão Conectiva com a Mandrake.
Mas ambos não tem o potencial do APT-GET em conjunto com o Synaptic utilizado pelo Debian e derivados.
DEB
Similar ao RPM, também trabalha com o gerenciamento através de um banco de dados de todos os pacotes disponíveis. Porém possui um diferencial que está fazendo crescer cada vez mais e ser um forte adversário ao RPM: APT-GET + Synaptic. Essa dupla vem conquistando cada vez mais fãs e uma coisa é unânime: é padrão para as distribuições baseadas em Debian. Há aquelas que utilizam o Adept que também trabalha muito bem. Mas no fundo é o APT-GET trabalhando. Com isso, hoje é muito mais comum ver sites disponibilizar pacotes DEB e até mesmo repositórios para distribuições Debian. Com esse padrão, o formato está ganhando cada vez mais força.
Atualizações fáceis, remoção de pacotes desnecessários, resolução de pacotes quebrados, opção de forçar determinada versão do pacote quando há várias disponíveis, prender uma versão dos pacotes para evitar que sejas atualizados quando há risco de incompatibilidade com alguns programas, salvar a lista dos pacotes selecionados em um arquivo para depois serem instalados sem a necessidade de ter que marcar tudo novamente, ver o histórico de todos os pacotes instalados, removidos, atualizados desde a instalação do Linux... Essas e muitas outras opões estão disponíveis para o administrador Linux através do DEB, APT-GET e Synaptic, gerando uma ferramenta extremamente poderosa.
TGZ
O TGZ é o padrão utilizado pelo Slackware, porém possui alguns problemas: um pacote pode ser instalado sem suas dependências, o que proporciona programas que não abrem. Falta uma ferramenta boa para gerência dos pacotes através de um sistema similar ao URPMI e APT-GET... Há o slackpkg que trabalha bem, mas é pobre de opões se compararmos ao APT-GET. Por isso é raro ver pacotes nesse formato.
Padrão
Esse é ponto chave para o Linux crescer. Por mais que RPM e DEB sejam fortes, um único sistema para gerenciar os pacotes impulsionaria o crescimento do Linux. Mark Shuttleworth do Ubuntu já apontou isso a pouco tempo e tem toda a razão. As funções estão bem parecidas e já está na hora de um padrão ser feito e adotado pelas distribuições Linux. Enquanto esse dia não chega, alguns fabricantes de software estarão desencorajados de desenvolver e disponibilizar seus programas para Linux
Há ferramentas importantes de serem citadas:
- APTITUDE: evolução do APT-GET e mais "inteligente" que o APT-GET. Porém algumas de suas funções estão sendo integradas ao APT-GET;
- Smart: criado pela antiga Conectiva, o padrão iria ser compatível com vários tipos de gerenciamento de pacotes, porém não se ouve mais falar como antes...
Espero que gostem deste artigo...
-
pra mim o melhor é o deb! ::)
-
Gostei Jefferson do seu relato e de sua experiência.
EU particularmente não posso falar que o apt é o melhor pois simplismente eu não tenho experiência em outros "package-managers".
Seria leviano da minha parte.
pra mim o melhor é o deb! ::)
Dhiego, vc já testou outros sistemas para afirmar que o apt-get é o melhor??
7355
-
Eu gosto do .deb pois ele é bem fácil e se você tiver problemas de dependências, ele resolve para você ( se tiver conectado à internet ), o .rpm eu nunca usei, já o .tgz ( tar.gz ) eu uso ele de vez em quando mas é um martírio sinceramente, pois ele não resolve o problema de dependências como o .deb...
Mas se fosse realmente adotar um padrão, eu gostaria muito pois isso de vários pacotes atrapalha muito, na minha opinião devemos deixar de lado um pouco essa parte de "multipacotes" e trabalhar em cima de um só, ficaria mais fácil entende?
-
pra mim o melhor é o deb! ::)
Dhiego, vc já testou outros sistemas para afirmar que o apt-get é o melhor??
7355
[/quote]
ahh..
para te falar a verdade eu nunca testei!
mas o que eu estou olhando em questão de estabilidade e essas coisas mais avançadas e estáveis!
o .deb ganha dos outros!
se eu estiver mal informado me corrigem OK?
[];S
-
O deb é melhor, pois é mais rápido para instalar, mais fácil de manter e atualizar, mais fácil para remover sem dar muitos problemas.
Já testei todos e cheguei a essa conclusão.
O tgz e o cata-cata de dependências é chato e o slaptget tem que melhorar um pouco mais. O rpm é lento e tem que melhorar em certos pontos.
O bom do apt é que ele é bem flexível. Depois que aprendi a usar o apt-get direito (valeu Mike) tenho um controle sobre tudo o que instalo e chegue a fazer um tutorial sobre isso.
http://www.guiadohardware.net/comunidade/tutorial-apt/812072/#post3386487
-
Realmente a falta de padrão de pacotes desencoraja desenvolvedores, mas isso é um assunto que já causou muita polêmica em outro tópico sem obter resultado nenhum.
O que poderia ser feito é um esforço para manter a compatibilidade das distros que usam o mesmo pacote, para que se possa instalar um pacote do fedora no mandriva, por exemplo, e funcionar do mesmo jeito, sem problemas.
Se eu não me engano, o pessoal do Debian se esforça para isso, o que é muito louvável.
Sabe, eu fico pensando, se o Linux continuar uma bagunça, com o perdão da palavra, o Solaris pode se tornar mais popular em desktops, e poderia até cair nas graças da indústria de software, já que solaris é solaris( bom, solaris tem 3 versões, mas todas da Sun, me corrijam se estiver errado ).
-
Livio, já existe algo neste sentido para os pacotes RPM. Outra coisa, vocês já viram o packagekit (http://www.packagekit.org/), ele pode vir a ajeitar as coisas, mais neste post do og Maciel http://blog.ogmaciel.com/?p=364
-
DEB!!!! ;D
E viva a praticidade!^^
Um Abraço a todos^^
-
JeffersonX, primeiramente quero te parabenizar pelo excelente artigo. E tbm ao que o Hqxriven postou sobre o APT no guiadohardware ;) Só gostaria de fazer algumas ressalvas, se vc me permite...
O APT-RPM está caindo cada vez mais em esquecimento depois da fusão Conectiva com a Mandrake.
Mas ambos não tem o potencial do APT-GET em conjunto com o Synaptic utilizado pelo Debian e derivados.
O PCLinuxOS utiliza essa relação das Debian Likes, porém substitui o apt-get pelo apt-rpm. Daí se tem, olha que interessante: APT-RPM + Synaptic rodando pacotes RPM (talvez daí poderia surgir algo relacionado à padronização, haja vista que o mecanismo funciona tbm em pacotes não-deb, só que lento ainda - vamos ver o que promete 2008)
- Smart: criado pela antiga Conectiva, o padrão iria ser compatível com vários tipos de gerenciamento de pacotes, porém não se ouve mais falar como antes...
O Smart ainda é bastante utilizado pelos usuários do OpenSUSE. Eu mesmo utilizei ele há um tempinho atrás no 10.13, pois o Smart é mais rápio que o Yast, msmo sendo obsoleto comparado com este ultimo.
Acho que era isso. Não falei do Slack pq seria "leviano" de minha parte, conforme disse o fabiovalinhos ;)
Acho que era isso só ;) Parabéns, cara! [ ]s
-
Depois de experimentar várias distros chego à conclusão que o apt/deb é o rei!
Mas gostei mesmo muito também do yum do fedora com rpm.
O pior mesmo é o yast do opensuse na minha opinião
-
Em uma discussão simples com meu irmão e amgos meus o maior problema é exatamente esse com relação ao linux para os usuários leigos. E principalmente é a dor de cabeça que uma empresa tem para gerar pacotes diferentes para diferentes distribuições... no linux apesar de existir o POSSIBILIDADES falta padrões, pelo pouco que li e conheço, muitos padrões ja foram atingidos, mas principalmente padrões para o usuário leigo ainda não existem muitos.
-
Em uma discussão simples com meu irmão e amgos meus o maior problema é exatamente esse com relação ao linux para os usuários leigos. E principalmente é a dor de cabeça que uma empresa tem para gerar pacotes diferentes para diferentes distribuições... no linux apesar de existir o POSSIBILIDADES falta padrões, pelo pouco que li e conheço, muitos padrões ja foram atingidos, mas principalmente padrões para o usuário leigo ainda não existem muitos.
Ouso discordar.
Todas as distros atuais têm algo como o "adicionar/remover" do Ubuntu, listando software por categoria e permitindo a instalação por um simples clique do mouse.
Algumas, inclusive, permitem que vc. instale programas pelo Firefox usando a opção "abrir com" + "instalador", exatamente como é feito no Windows, mas sem os riscos presentes naquele SO.
Isso é muito mais fácil do que usar Windows, onde vc. precisa encontrar um programa livre (e não são muitos), baixar, checar com um bom antivírus e instalar.
E se o programa for proprietário? Aí é preciso sair atrás de cracks e keygens que quase sempre instalam vírus, trojans, backdoors etc. e enquanto vc. está se achando muito esperto, sua máquina está enviando spam e mais malware pela Net sem que vc. perceba.
-
E se o programa for proprietário? Aí é preciso sair atrás de cracks e keygens que quase sempre instalam vírus, trojans, backdoors etc. na sua máquina e, enquanto vc. está se achando muito esperto, sua máquina está enviando spam e mais malware pela Net sem que vc. perceba.
São os famosos "computadores zumbis"
-
Muita gente atribui ao sistema de gerenciamento de pacotes (RPM, DEB, TGZ, etc.) atributos que, na verdade, são do metagerenciador de pacotes (APT-GET, YUM, URPMI, slackpkg, swaret, etc.). O que é tão rápido, o tar.gz.pkg (sistema de gerenciamento de pacotes da Arch Linux) ou o metagerenciador, o pacman? É difícil dizer sem conhecê-los profundamente.
Veja o caso do Suse, por exemplo. Uma coisa é a velocidade do processo de instalação quando este é efetuado pelo ZenWorks, outra coisa é o mesmo processo quando efetuado pelo Smart ou apt-rpm. Mas o pacote não é o mesmo, RPM? Sim, mas para o sucesso de um metagerenciador há coisas tão importantes quanto o tipo de pacote. E o processo de controle das dependências, por exemplo? Como ele é efetuado? E a busca e transferência dos pacotes nos respectivos repositórios? Este é outro ponto importante. Isto sem contar com a velocidade dos próprios servidores: testei nestes últimos dias o PISI, gerenciador de pacotes da distro turca Pardus. Uma simples troca de repositórios deu um impulso e tanto na velocidade de instalação.
Enfim, acho que as pessoas confundem um pouco as coisas. Poderia perfeitamente haver pacote TGZ com controle de dependências. Até porque há vários tipos de controle de dependências. A Zenwalk introduziu o controle de dependências no seu metagerenciador netpkg sem mudar nada na estrutura do pacote TGZ. Se não há controle de dependências na Slackware isto se deve a uma certa concepção de sistema do Patrick Volkerding e outro líderes do projeto e não a uma característica substancial ao próprio TGZ.
Por fim, o interessante é que embora todo dia haja alguém dizendo por aí que o Linux precisa de um sistema único a verdade é que é difícil passar um mês sem que surja um novo sistema de gerenciamento de pacotes...Sempre há alguém que acha ter um aprimoramento importante e que não é ouvido pelos colegas. Então, por que não criar um novo sistema? E quem vai impedir? O Diretor-Presidente do Linux S/A?
-
Piras até tem lógica o que disseste mas por exemplo, como explicas a lentidão do apt-rpm do PclinuxOS?
O apt-deb no debian ou no ubuntu é um foguete e o apt do pclinuxos com rpm é uma carroça.
Terá aqui alguma influencia ser deb ou rpm?
Quanto ao opensuse concordo plenamene contigo. O yast é muito mau, mesmo sem o zenworks, já com o smart o ganho em velocidade era notável
-
Piras até tem lógica o que disseste mas por exemplo, como explicas a lentidão do apt-rpm do PclinuxOS?
O apt-deb no debian ou no ubuntu é um foguete e o apt do pclinuxos com rpm é uma carroça.
Terá aqui alguma influencia ser deb ou rpm?
cara, eu descobri que a lentidão não é do apt-rpm (q chama apt-get) mas sim dos repositorios do pclos. Eu criei em meu host um repositorio especifico, pra testar, com os pacotes rpm que uso, e apontei pra ele (criei até uma chave de autenticação - éeee ficou bacana ;)) e com o sistema recém instalado, na hora de atualizar, funcionou bem mais rapido do que aquele repositorio oficial de indiana lá que o pclinuxos tem. na verdade, no synaptic, se desabilitar o primeiro repositorio padrao da distro e habilitar o segundo, e fizer a atualização, ocorre quase o dobro de velocidade, alguem fez esse teste?
o apt do ubuntu faz downloads simultaneos, ao passo que o do pclos faz individual ainda (mas está na versao 2007 - vamos ver na 2008 se vao melhorar ele)
tenho que dar o braço a torcer e reconhecer que os repositorios da canonical sao os melhores que conheço
abraços a vcs todos, amigos ;)
-
Piras até tem lógica o que disseste mas por exemplo, como explicas a lentidão do apt-rpm do PclinuxOS?
O apt-deb no debian ou no ubuntu é um foguete e o apt do pclinuxos com rpm é uma carroça.
Terá aqui alguma influencia ser deb ou rpm?
Quanto ao opensuse concordo plenamene contigo. O yast é muito mau, mesmo sem o zenworks, já com o smart o ganho em velocidade era notável
Bem, caro sylvester, o amigo Eunir respondeu a sua questão. Sempre defendi que a lentidão do APT na PCLinuxOS não se devia somente ao metagerenciador de pacotes, mas, sobretudo, a qualidade dos servidores dos repositórios oficiais. É claro que o apt-get têm sofrido alguns aperfeiçoamentos que dão maior velocidade ao programa. Estou certo de que tais modificações não chegaram ainda ao apt-rpm, adotado pela PCLinuxOS. No entanto, isto não explicava toda a lentidão dos processos de instalação e atualização no apt-rpm.
Recomendo uma experiência muito simples. Todo sabemos que o APT acumula os pacotes deb transferidos para o sistema numa pasta do diretório /var. Se removermos um probrama ou biblioteca e quisermos fazer a instalação novamente é nesta pasta /var que o APT começara a procura do programa ou biblioteca, certo? Então faça o seguinte teste: remova no Ubuntu e no PCLinuxOS um determinado programa, cujo deb esteja já salvo na pasta /var/cache/apt/archives. Se houver muita diferença de velocidade entre os dois processo, o problema então é do apt-rpm mesmo. Estou enganado. Mas se não houver diferença sensível, então o problema é do repositório.