Diferenças no gerenciamento de pacotes entre o Debian e o Arch


9

Uma discussão deste post me deixou curiosa sobre as diferenças entre o gerenciamento de pacotes Debian e Arch. Além disso, as pessoas tendem a dizer que o Arch é muito leve, então eu me pergunto o que isso tem a ver com o gerenciamento de pacotes. Talvez porque o Debian trate as Recomendações como dependências rígidas por padrão?

Você também pode mencionar a flexibilidade / poder entre os dois gerenciadores de pacotes: qual dos dois permite fazer mais.

Estou ciente de que alguns recursos disponíveis em um sistema de gerenciamento de pacotes Debian seriam irrelevantes em um sistema Arch, uma vez que o Arch possui uma única suíte e o Debian possui vários (por exemplo, fixação do APT e tratamento avançado de dependências); portanto, compare os recursos que são aplicáveis ​​a ambos os sistemas (isto é, suponha que, para o Debian, eu apenas uso instável ).


NOTA : Pelo gerenciamento de pacotes Debian, estou me referindo ao APT, aptitude e dpkg. Eu não estou familiarizado com as ferramentas do Arch, então não sei se há algo além de Pacman.
tshepang

Respostas:


7

Eu apenas uso o arco regularmente há algumas semanas e não sou especialista no assunto, então esta resposta não é de forma alguma exaustiva, apenas alguns pontos que observei sobre a "flexibilidade / poder":

  • Isso é apenas uma impressão, mas o 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, apenas olhei o código libalpm (a biblioteca subjacente do 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 se importando com poucas 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.

  • Enquanto o arch é orientado para o uso de pacotes binários, também possui vantagens ao criar pacotes a partir do código-fonte, com um sistema de compilação semelhante às portas do BSD (ABS).

  • É muito fácil e rápido criar pacotes, apenas algumas linhas em um arquivo PKGBUILD e pronto, não há necessidade de lidar com control / rules / copyright / changelog / como os pacotes Debian. E com apenas alguns cliques em uma interface do usuário na web, seu pacote é compartilhado com todos no AUR (Arch User Repository).

Coisas que recebo no Debian e não no arco:

  • Triggers / hooks (o que faz o apt atualizar o cache de ícones, o mandb ou o que quer que seja, apenas olhando para onde o pacote instala os arquivos, sem a necessidade do empacotador fazer nada) (parece que há planos para implementá-lo).

  • debconf (nada demais e, a propósito, forçando-me a fazer as coisas manualmente, ele me força a saber o que exatamente é feito) e o manuseio adequado dos novos arquivos de configuração (eu gostaria que o pacman soubesse quando um arquivo de configuração em um novo pacote versão é diferente da instalada porque foi alterada na nova versão ou porque a modifiquei localmente).

  • assinatura de pacote (parece que está sendo trabalhado ).

Por ser leve, o único motivo real é que ele vem com poucos pacotes instalados por padrão e você é incentivado a adicionar o que você precisa, portanto, provavelmente não instalar dependências opcionais por padrão está incentivando os usuários a instalar o inchaço.


Não posso analisar isso: mas posso ficar sem ele e, a propósito, saber o que faço melhor . Há também um erro de digitação na última frase.
tshepang

Em que idioma está escrito o gerenciador de pacotes pacman? Possui funcionalidade de gerenciamento de pacotes de baixo e alto nível semelhante ao dpkg / apt e, em caso afirmativo, como eles são chamados?
Faheem Mitha 27/03

@Tshepang: desculpe, falante de inglês não nativo aqui. Eu quis dizer "isso não é grande coisa para eu não ter essa funcionalidade (debconf) e forçando-me a fazer as coisas manualmente, isso me força a saber o que exatamente é feito".
### gentledevil #

@ Faaem Mitha: O Pacman é escrito em C e é um frontend para libalpm, que lida com o gerenciamento de pacotes "de alto nível" e "de baixo nível".
31811 gentledevil

@ zanko: Eu também não sou um falante nativo. Tudo o que eu queria que você fizesse é tornar a frase mais clara, e não em um comentário, mas no próprio post. Aliás, o erro de digitação que mencionei é opcional . Eu mesmo poderia editar a postagem, mas achei que você poderia corrigi-la juntamente com a parte do esclarecimento.
tshepang

6

Comecei minha jornada do 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, gostaria de salientar ao @gentledevil que o Arch possui um sistema de ganchos para pacotes, conhecido como install file.

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

Além disso, notei que você mencionou 'fixar' um aplicativo usando ferramentas de gerenciamento de pacotes debian; O pacman do Arch também possui esse recurso, /etc/pacman.confaceita várias configurações, incluindo IgnorePkg =, o que impedirá atualizações para qualquer pacote listado após os iguais (delimitado por espaço)


11
Além disso, embora não seja um pacote repo, você pode usar o powerpillwrapper para o pacman para fazer downloads paralelos de vários pacotes; portanto, ao invés de pacman -S libfoo libbar libbazbaixar cada pacote um após o outro, ele baixaria os três simultaneamente, aumentando muito a velocidade de atualização para melhores conexões.
hanetzer

-1

Antes de eu ir longe demais, estude a Linha do tempo do Pictorial Linux

Para entender as diferenças nos gerenciadores de pacotes, você deve entender as filosofias dos SOs mostrados acima


Três pais principais

  1. Redhat, Now 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 criados pelo Slackware upstream e colocados em um repositório, às vezes chamado de 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 idéia / conceito de um Sistema de Gerenciamento de Pacotes foi derivada ou compartilhada de alguma forma ou moda. Independentemente disso, todos esses pais são distribuidores binários, o que significa que um programa é empacotado e decidido por terceiros, depois armazenado em um repositório e consumido ou instalado pela base de usuários.

3 Pais Menores

  1. Linux From Scratch - baseado em fonte, sem gerenciador de pacotes.
  2. Gentoo - Derivado do Linux a partir do zero . Esta distribuição é essencialmente Linux from Scratch mais um gerenciador de pacotes, chamado Portage / emerge
  3. SourceMage - Feitiço do Gerenciador de Pacotes

Esses pais são menores porque sua base de usuários comercializa velocidade e facilidade de instalação com energia e facilidade de configuração. Cada pacote é baixado e compilado a partir do zero, usando variáveis ​​e arquivos de configuração.

A Ponte

O Arch foi criado como uma ponte entre uma distribuição binária, como um dos 3 Pais Principais, e uma distribuição baseada em 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. O Pacman tem a flexibilidade de permitir que um usuário instale um pacote binário de um repositório oficial ou um pacote personalizado usando o Arch Build System. Esse conceito fornece um equilíbrio entre o poder que os pais menores dão com a facilidade de instalação que os pais principais dão.


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

  • Nível de usuário: alguém novo no linux deve começar com um pai principal, enquanto alguém tecnicamente competente encontrará um equilíbrio.
  • O que você deseja fazer com o seu sistema: A execução de um servidor LAMP com usuários conectados é totalmente diferente da execução de um PC de mesa para navegação na Web e leitura de e-mail.
  • Nível de conforto: o nível do usuário não é afetado, se você é tecnicamente competente, mas não quer passar um fim de semana compilando um sistema, escolherá um dos principais pais, independentemente de todos que conhecerem escolherem outra coisa.

Isso é mais focado no geneaology das distribuições, em vez de uma comparação de pacman e ferramentas de gerenciamento de pacotes do Debian ...
jasonwryan

@jasonwryan Esse é o ponto, pois todos os gerenciadores de pacotes realizam a mesma tarefa, ou seja, emerge packagenamesão os mesmos que sudo apt-get install packagename.
eyoung100

Nesse nível, sim; mas isso ignora completamente o ponto da questão, ou seja, o que diferencia pacman de {apt, aptitude}.
jasonwryan

@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 estiver procurando diferenças semânticas, existe um manual para isso.
eyoung100

-3

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

pacman é muito fácil de usar, o que é um profissional e um trapaceiro - você pode aprender a usá-lo (criação de pacotes à parte) em uma única tarde - ele 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 - é necessário fazer o download dessa versão específica do pacote e usar a opção -U (upgrade) para instalar a partir do arquivo. É muito voltado para o uso sempre de pacotes de ponta em seu sistema.

Não há limpeza de cache interno real / reconstrução completa. Se (devido a um problema de rede) um download do pacote estiver corrompido, por exemplo, durante -Syu, a mensagem de erro, embora precisa, não será muito útil - não identificará o pacote corrompido, mesmo com a verbosidade "completa" e a depuração ativadas. , e nenhuma quantidade de -Syyc realmente limpará o cache e fará o download novamente dos pacotes. A boa notícia é que -Sc permitirá que você saiba onde estão os pacotes baixados, para que você possa simplesmente remover o que está causando o problema (se conseguir descobrir qual é) ou todos eles e reiniciar o -Syu.

a integração do pacman com o dkms também é um pouco problemática - ao instalar um novo kernel, eu continuava tendo erros do dkms. O uso do dkms build && dkms install contra o novo kernel funcionou sem problemas, mas o pacman não forneceu nenhuma informação sobre por que os dkms falharam durante a atualização do kernel (suspeito que nunca tenha passado o caminho correto do novo kernel e deixe o dkms usar o padrão (em execução), mas com a versão errada).

Outra anedota sobre sua inflexibilidade - como afirmado, estou acostumado a rpm / ano. Se eu tenho um arquivo no meu sistema e gostaria de saber qual pacote o possui, eu posso executar o yum fornece / path / to / file e obter TODOS os pacotes que podem colocá-lo lá - mesmo que nenhum deles esteja instalado. Se o arquivo foi colocado manualmente, e agora desejo instalar um pacote - ele renomeará o novo (adicione a extensão .rpmnew) e deixe-me escolher o que usar.

pacman simplesmente exclui que um arquivo já existe, mas com uma mensagem de erro completamente irrelevante - queixa-se de conflitos entre o proprietário "true" do arquivo e o pacote "filesystems" atualmente instalado, como se também fosse o proprietário do mesmo arquivo. Além disso, é principalmente voltado para informações instaladas locais - 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 o yum, e provavelmente o dpkg, que também contribui para a facilidade de uso, é a relativa flexibilidade.


11
Com exceção de uma não resposta abrangente, há uma série de pontos que você levanta que realmente são produto de um desconhecimento do pacman. Por exemplo pacman -Qo $file, dirá qual pacote possui o arquivo $. Além disso, toda a sua resposta é simplória, já que o OP pediu explicitamente diferenças entre o Arch e o Debian - yumnão tem nada a ver com isso ...
jasonwryan

foi por isso que expliquei esse fato explicitamente no início da minha resposta. quanto ao arquivo -Qo $ - você já tentou isso para um pacote ainda não instalado?
114414 Dani_l

Não faz sentido tentar um pacote não instalado; existem outras ferramentas para isso. E a divulgação não atenua o fato de você não ter respondido à pergunta: uma "comparação" entre yum e pacman não é a mesma que as diferenças entre os gerenciadores de pacotes do Debian e do Arch.
jasonwryan

@jasonwryan Claro que há um ponto. Só porque você não vê a necessidade de descobrir qual pacote pode possuir um arquivo, mesmo que ainda não esteja instalado, não significa que essa necessidade não exista. Esse era o ponto. Quanto a outras ferramentas - elas precisam conhecer a base? pacman é o gerenciador de pacotes. Em relação ao seu ponto principal - eu posso ter lido completamente a pergunta, mas presumi que se tratava de um PM leve e um PM mais complexo. Eu assumo que o apt / dpkg seja pelo menos tão complexo quanto o yum / rpm, em termos de recursos.
114414 Dani_l

O que quero dizer é que você está respondendo a uma pergunta sobre a comparação de maçãs com laranjas, comparando sua compreensão limitada de maçãs com peras. E sim, você ter descaracterizou completamente a questão ...
jasonwryan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.