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 ).
fonte
Respostas:
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.
fonte
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, incluindoIgnorePkg =, o que impedirá atualizações para qualquer pacote listado após os iguais (delimitado por espaço)fonte
powerpillwrapper para o pacman para fazer downloads paralelos de vários pacotes; portanto, ao invés depacman -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.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
rpmAptitude or AptEsses 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
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:
fonte
emerge packagenamesão os mesmos quesudo apt-get install packagename.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.
fonte
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 ...