Diferenças no gerenciamento de pacotes entre Debian e Arch

Eu uso o arch regularmente há algumas semanas e não sou nenhum especialista no assunto, portanto esta resposta não é exaustiva, apenas alguns pontos que observei sobre a “flexibilidade / poder”:

• Isso é apenas uma impressão, mas pacman parece mais moderno e simples em seu design / arquitetura. Pelo menos há muito menos ferramentas para lidar. Embora eu não conheça o código-fonte do apt, acabei de olhar para o código libalpm (a biblioteca subjacente ao pacman) para fazer um patch muito simples e parece limpo e fácil de entender.

• Também é muito rápido (devido à otimização e também provavelmente por se preocupar com algumas coisas (veja abaixo)). A última versão (pacman 3.5, alguns dias atrás) tentou melhorar o desempenho reduzindo o número de arquivos de banco de dados envolvidos.

• Embora o arch seja orientado para o uso de pacotes binários, ele também tem vantagens ao construir pacotes a partir do código-fonte, com um sistema de construção semelhante aos ports do BSD ( ABS).

• É muito fácil e rápido criar pacotes, apenas algumas linhas em um arquivo PKGBUILD e está feito, não há necessidade de lidar com controle / regras / direitos autorais / changelog / qualquer que seja como com os pacotes Debian. E com alguns cliques em uma interface do usuário da web seu pacote é compartilhado com todos no AUR (Arch User Repository). no Debian e não no arch:

  • Triggers / h ooks (o que faz o apt atualizar o cache de ícones, o mandb ou o que quer que seja apenas olhando onde os arquivos de instalação do pacote, sem a necessidade de o empacotador fazer nada) (parece que existem planos para implementar isso).

  • debconf (não é grande coisa e, a propósito, por me forçar a fazer as coisas manualmente, ele me força a saber o que exatamente é feito) e manuseio adequado de novos arquivos de configuração (eu gostaria que o pacman soubesse quando um arquivo de configuração em uma nova versão do pacote é diferente do instalado porque foi alterado na nova versão ou porque eu o modifiquei localmente).

  • assinatura do pacote (parece que está trabalhando ).

  Por ser o arch leve, a única razão real é que ele vem com poucos pacotes instalados por padrão e você “é encorajado a adicionar o que precisa, então provavelmente não instalar dependências opcionais por padrão está incitando os usuários a instalar para evitar inchaço .

  Comentários

  • Posso ‘ analisar isso: mas posso fazer sem ele e, a propósito, sei o que faço melhor . Também há um erro de digitação na última frase.
  • Em que idioma o gerenciador de pacotes pacman está escrito? Ele tem funcionalidade de gerenciamento de pacotes de baixo e alto nível semelhante a dpkg / apt, e se sim, como são chamados?
  • @Tshepang: desculpe, falante não nativo de inglês aqui. Eu quis dizer ” não é grande coisa para mim não ter essa funcionalidade (debconf) e, ao me forçar a fazer as coisas manualmente, me força a saber exatamente o que é feito “.
  • @Faheem Mitha: Pacman é escrito em C e é um frontend para libalpm, que lida com ” alto -nível ” e ” nível baixo ” gerenciamento de pacotes.
  • @zanko: I ‘ também não sou falante nativo. Só queria que você deixasse a frase mais clara, e não em um comentário, mas no próprio post. BTW, o erro de digitação que mencionei é opcional . Eu poderia editar a postagem sozinho, mas achei que você poderia também corrigi-lo junto com a parte de esclarecimento.

Comecei minha jornada no Linux com o Ubuntu lucid e atualmente uso o Arch.Eu escrevi um punhado de pacotes Arch e direi que é muito mais fácil do que escrever pacotes Debian. Mas, eu “gostaria de apontar para @gentledevil que o Arch tem um sistema de ganchos para pacotes, conhecido como install file.

Basicamente, é denominado ${pkgname}.install e contém algumas funções para pré / pós-instalação / remoção / atualização; basta colocar as atualizações do cache de fontes nisso e assim por diante, e funciona quase da mesma forma que os ganchos do Debian.

Além disso, eu percebi que você mencionou “fixar” um aplicativo usando ferramentas de gerenciamento de pacotes debian; o pacman do Arch tem isso embutido também, /etc/pacman.conf aceita uma série de configurações, incluindo IgnorePkg =, que impedirá atualizações de quaisquer pacotes listados após os iguais (delimitados por espaço )

Comentários

• Além disso, embora não seja um pacote repo, você pode usar o powerpill wrapper para que o pacman tenha downloads paralelos de vários pacotes, então em vez de pacman -S libfoo libbar libbaz baixar cada pacote um após o outro r em vez disso, baixaria todos os três simultaneamente, aumentando muito as velocidades de atualização para melhores conexões.

Antes de mim vá longe demais, estude a Linha do tempo Pictorial do Linux

Para entender as diferenças nos gerenciadores de pacotes, você deve entender as filosofias do sistema operacional ” na foto acima

Três pais principais

1. Redhat, agora Fedora – Gerenciador de pacotes – RPM, abreviação de Redhat Package Manager, linha de comando rpm
2. Slackware – Gerenciador de pacotes – tgz, arquivos compactados comuns. Embora sejam apenas arquivos compactados, eles foram construídos pelo Slackware upstream e colocados em um repositório, às vezes referido como uma porta
3. Debian – DEB, abreviação de Debian, sua ferramenta de linha de comando é Aptitude or Apt

Esses pais são mães e pais para a maioria das distribuições que conhecemos hoje. A ideia / conceito de um Sistema de gerenciamento de pacotes foi derivado ou compartilhado em alguns De qualquer forma, todos esses pais são distribuidores binários, o que significa que um programa é empacotado e decidido por um terceiro, depois armazenado em um repositório e consumido ou instalado pela base de usuários.

3 Pais menores

1. Linux From Scratch – Source Based, sem package manager.
2. Gentoo – Derivado de Linux from Scratch . Esta distribuição é essencialmente Linux from Scratch mais um gerenciador de pacotes, chamado Portage / emerge
3. SourceMage – Package Manager Sorcery

Estes pais são menores porque sua base de usuárioscomercializa velocidade e facilidade de instalação com potência e facilidade de configuração. Cada pacote é baixado e compilado do zero, usando variáveis e arquivos de configuração.

The Bridge

O Arch foi criado como uma ponte entre uma distribuição binária, como um dos 3 principais pais, e uma distribuição baseada na fonte, como um dos 3 pais menores. Como tal, ele recebe o status de pai na linha do tempo, porque nenhum outro pai forneceu essa funcionalidade. Pacman tem a flexibilidade de permitir que um usuário instale um pacote binário de um repositório oficial, ou um pacote customizado usando o Arch Build System. Este conceito fornece um equilíbrio entre o poder que os pais menores dão com a facilidade de instalação que os pais maiores oferecem.

Na minha opinião, não é o gerenciador de pacotes que mostra o poder de um sistema, já que todos os gerenciadores de pacotes fazem a mesma tarefa, que é gerenciar e manter um sistema saudável. Como tal, o sistema que você usa deve ser determinado por fatores como:

• Nível do usuário: Alguém novo no Linux deve começar com um pai principal, enquanto alguém tecnicamente proficiente encontrará um equilíbrio.
• O que você deseja fazer com seu sistema: rodar um servidor LAMP com usuários conectados é totalmente diferente de rodar um PC desktop para navegação na web e leitura de e-mail.
• Nível de conforto: nível de usuário não obstante, se você for tecnicamente proficiente, mas não quiser passar um fim de semana compilando um sistema, você escolherá um pai principal, independentemente de todos que você conhece escolher outra coisa.

Comentários

• Isso é mais focado ussed na genética das distribuições, em vez de uma comparação entre pacman e Debian ‘ s ferramentas de gerenciamento de pacotes …
• @jasonwryan That ‘ é o ponto, já que todos os gerenciadores de pacotes realizam a mesma tarefa, ou seja, emerge packagename é o mesmo que sudo apt-get install packagename.
• Nesse nível, sim; mas isso ignora totalmente o ponto da questão, ou seja, o que diferencia o pacman de {apt, aptitude}.
• @jasonwryan Eu respondi isso na seção The Bridge. Fora isso, não há diferença. As únicas diferenças são semânticas, ou seja, um comando versus outro.Se o OP está procurando por diferenças semânticas, existe um manual para isso.

Isto é por não significa uma resposta completa ou exaustiva – os pôsteres antes de mim já deram alguns pontos muito bons, eu gostaria apenas de adicionar meus 2 centavos. Outra coisa – eu nunca realmente me acostumei com apt / dpkg. Sempre pareceu muito complexo para eu, estou realmente mais confortável com yum / rpm.

O pacman é muito fácil de usar, o que é um prós e um contra – você pode aprender a usá-lo (criação de pacotes à parte) em uma única tarde – usa principalmente recursos de gerenciamento de pacotes intuitivos e completos, mas – e este é um grande mas – é extremamente inflexível.

Se os designers não pensaram em um recurso de antemão, você está ferrado.

Alguns exemplos: não há versão nativa no pacman. Se você deseja fazer o downgrade de uma versão do pacote – você deve fazer o download dessa versão do pacote em particular e usar a opção -U (upgrade) para instalar a partir do arquivo. é muito voltado para alwa ys usando pacotes de última geração em seu sistema.

Não há limpeza de cache interno real / reconstrução completa. Se (devido a um problema de rede) o download de um pacote foi corrompido, por exemplo, durante -Syu, a mensagem de erro, embora precisa, não será de muita utilidade – ela não identificará o pacote corrompido mesmo com a verbosidade “total” e a depuração ativadas , e nenhuma quantidade de -Syyc vai realmente limpar o cache e baixar os pacotes novamente. A boa notícia é que -Sc irá informá-lo onde estão os pacotes baixados para que você possa simplesmente remover o que está causando o problema (se você conseguir descobrir qual é) ou todos eles e reiniciar -Syu.

A integração do pacman com o dkms também é um tanto problemática – ao instalar um novo kernel, eu continuava tendo erros do dkms. Usar dkms build & & dkms install no novo kernel funcionou sem problemas, mas o pacman não ofereceu nenhuma informação por que o dkms falhou durante o atualização do kernel (eu suspeito que nunca passou no caminho correto do novo kernel, e apenas deixe o dkms usar o kernel padrão (atualmente em execução), mas com a versão errada).

Outra anedota sobre sua inflexibilidade – como declarado, estou acostumado a rpm / yum. Se eu tiver um arquivo em meu sistema e quiser saber qual pacote o possui, posso executar yum comes / path / to / file e obter TODOS os pacotes que podem colocá-lo lá – mesmo se nenhum deles estiver instalado. Se o arquivo foi colocado manualmente, e agora eu desejo instalar um pacote – ele irá renomear o novo (adicionar a extensão .rpmnew) e me deixar escolher o que usar.

pacman simplesmente informa que um arquivo já está existe, mas com uma mensagem de erro completamente irrelevante – ele reclama de conflitos entre o “verdadeiro” dono do arquivo e o pacote “sistemas de arquivos” atualmente instalado, como se também fosse o dono do mesmo arquivo. Além disso, é principalmente voltado para informações locais instaladas – tentar obter informações (como listas de arquivos e propriedade) de pacotes ainda não instalados é menos intuitivo.

Simplificando – não é tão maduro quanto yum, e provavelmente o dpkg, que também oferece facilidade de uso, é relativa inflexibilidade.

Comentários

• Curto de uma não resposta abrangente, há uma série de pontos que você levantou que realmente são produto de sua falta de familiaridade com o pacman. Por exemplo, pacman -Qo $file dirá qual pacote possui $ file. Além disso, toda a sua resposta é um espantalho, já que o OP pediu explicitamente as diferenças entre o Arch e o Debian – yum não tem nada a ver com isso …
• é por isso que revelei explicitamente esse fato no início da minha resposta. quanto ao arquivo -Qo $ – você já tentou isso para um pacote ainda não instalado?
• Não vale a pena tentar para um pacote não instalado; existem outras ferramentas para isso. E a divulgação não ‘ t atenua o fato de que você não ‘ t respondeu à pergunta: a ” comparação ” entre yum e pacman não é o mesmo que as diferenças entre Debian ‘ s e Arch ‘ s gerenciadores de pacotes.
• @jasonwryan Claro que há um ponto. Só porque você não ‘ não vê a necessidade de descobrir qual pacote pode ter um arquivo, mesmo que ‘ ainda não esteja instalado, não ‘ significa que tal necessidade não ‘ não existe. Esse era o ponto. Quanto às outras ferramentas – elas são baseadas na necessidade de saber? pacman é o gerenciador de pacotes. Com relação ao seu ponto principal – posso ter interpretado mal a pergunta, mas presumi que fosse sobre um MP leve versus um MP mais complexo. Suponho que apt / dpkg seja pelo menos tão complexo quanto yum / rpm, em termos de recursos.
• Meu ponto é que você está respondendo a uma pergunta sobre comparar maçãs com laranjas comparando seu conhecimento limitado de maçãs com peras. E sim, você interpretou mal a pergunta …