Diferenças no gerenciamento de pacotes entre Debian e Arch

Question

Uma discussão de esta postagem me fez curioso de 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 trata Recomenda como dependências difíceis 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, já que o Arch possui um conjunto único e o Debian possui múltiplos (por exemplo, manipulação de APT e tratamento de dependência avançada). comparar recursos que são aplicáveis a ambos os sistemas (isto é, suponha que para o Debian, eu só uso unstable ).

    

Answer 1

Eu só uso arco regularmente desde algumas semanas e não sou especialista no assunto, então esta resposta não é de forma exaustiva, apenas alguns pontos que tenho notado 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 saiba do código-fonte do apt, por acaso eu observei o código libalpm (a biblioteca subjacente ao pacman) para fazer um patch muito simples, e ele parece limpo e fácil de entender.

• Também é muito rápido (devido à otimização e também provavelmente por se preocupar 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.

• Embora o arch seja orientado para o uso de pacotes binários, ele 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, sem necessidade de lidar com control / rules / copyright / changelog / qualquer que seja o tipo de pacote Debian. E com apenas alguns cliques em um web ui seu pacote é compartilhado com todos no AUR (Arch User Repository).

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

• Triggers / hooks (o que faz o apt atualizar o cache de ícones, o mandb ou qualquer outro, apenas olhando para onde o pacote instala os arquivos, sem que o empacotador precise fazer nada) (parece que existem plans para implementar isso).

• debconf (não é grande coisa e, a propósito, forçando-me a fazer as coisas manualmente, obriga-me a saber exatamente o que é feito) e a manipulação adequada de novos arquivos de configuração (gostaria pelo menos de pacman O arquivo de configuração em uma nova versão do pacote é diferente do arquivo instalado porque foi alterado na nova versão ou porque eu o modifiquei localmente).

• assinatura de pacote (parece estar sendo trabalhado em ).

Para o arch light, a única razão real é que ele vem com alguns pacotes instalados por padrão e você é encorajado a adicionar o que você precisa, então provavelmente não instalar dependências opcionais por padrão é incitar os usuários a instalarem evitar o inchaço.

    

Answer 2

Comecei minha jornada no Linux com o Ubuntu lúcido e atualmente uso o Arch. Eu escrevi um punhado de pacotes do Arch, e eu digo que é muito mais fácil do que escrever pacotes Debian. Mas, eu gostaria de salientar 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; apenas coloque suas atualizações de cache de fontes nisso e assim por diante e ele funciona da mesma forma que os ganchos da Debian.

Além disso, notei que você mencionou 'fixar' um aplicativo usando ferramentas de gerenciamento de pacotes da Debian; O pacman do Arch também possui built-in, /etc/pacman.conf aceita uma série de configurações, incluindo IgnorePkg = , o que impedirá atualizações para quaisquer pacotes listados após os iguais (delimitados por espaço)

    

Answer 3

Antes de ir longe demais, estude o Cronograma Pictorial do Linux

Para entender as diferenças entre os gerentes de pacotes, você deve entender as filosofias dos sistemas operacionais descritos acima

Três pais principais

1. Redhat, Now Fedora - Gerenciador de Pacotes - RPM, abreviação de Gerenciador de Pacotes Redhat, 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 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 da 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 forma. Independentemente disso, 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 - Baseado na origem, sem gerenciador de pacotes.
2. Gentoo - Derivado do Linux from Scratch . Esta distribuição é essencialmente Linux do 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 negocia velocidade e facilidade de instalação com poder e facilidade de configuração. Cada pacote é baixado e compilado 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 na fonte como um dos 3 Pais Menores. Dessa forma, ele recebe 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 a partir de um repositório oficial ou de um pacote personalizado 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 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, que é gerenciar e manter um sistema saudável. 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 maior, enquanto alguém com proficiência técnica encontrará um equilíbrio.
• O que você deseja fazer com 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: nível de usuário inapto, se você for tecnicamente proficiente, mas não quiser passar um final de semana compilando um sistema, escolherá um pai ou mãe maior, independentemente de todos que você escolher escolher outra coisa.

Answer 4

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

O pacman é muito fácil de usar, o que é um prós e contras - você pode aprender a usá-lo (construção de pacotes) em uma única tarde - ele usa recursos de gerenciamento de pacotes intuitivos e completos, mas - e isso é 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ê quiser fazer o downgrade de uma versão do pacote - você precisa baixar essa versão específica do pacote e usar a opção -U (upgrade) para instalar a partir do arquivo. É muito voltado para o uso de pacotes de ponta em seu sistema.

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

A integração do pacman com dkms também é um pouco problemática - ao instalar um novo kernel eu continuei tendo erros do dkms. Usando o dkms build & & dkms install contra o novo kernel funcionou sem problemas, mas o pacman não ofereceu nenhuma informação por que o dkms falhou durante a atualização do kernel (eu suspeito que ele nunca passou pelo caminho correto do novo kernel e apenas deixe o dkms usar o padrão) kernel, mas com a versão errada).

Outra anedota sobre sua inflexibilidade - como dito, estou acostumado a rpm / yum. Se eu tiver um arquivo no meu sistema e eu quiser saber qual pacote possui, eu posso rodar o yum provendo / path / to / file e pegar TODOS os pacotes que podem colocá-lo lá - mesmo que nenhum deles esteja instalado. Se o arquivo foi colocado manualmente, e agora eu quero instalar um pacote - ele irá renomear o novo (adicionar extensão .rpmnew), e deixe-me escolher o que usar.

O pacman simplesmente descarta que um arquivo já existe, mas com uma mensagem de erro completamente irrelevante - queixa de conflitos entre o proprietário do arquivo "verdadeiro" e o pacote "filesystems" atualmente instalado, como se também fosse um proprietário do arquivo mesmo arquivo. Também é 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 - ele não é tão maduro quanto o yum, e provavelmente o dpkg, que também é fácil de usar, é uma inflexibilidade relativa.