Différences dans la gestion des paquets entre Debian et Arch


9

Une discussion de ce post m'a rendu curieux des différences entre la gestion des paquets Debian et Arch. De plus, les gens ont tendance à dire qu'Arch est très léger, donc je me demande ce que cela a à voir avec la gestion des paquets. Est-ce peut-être parce que Debian traite les recommandations comme des dépendances matérielles par défaut?

Pouvez-vous également mentionner la flexibilité / puissance entre les deux gestionnaires de paquets: lequel des deux vous permet d'en faire plus.

Je suis conscient que certaines fonctionnalités disponibles sur un système de gestion de paquets Debian ne seraient pas pertinentes sur un système Arch, car Arch a une seule suite et Debian en a plusieurs (par exemple, l'épinglage APT et la gestion avancée des dépendances viennent à l'esprit), veuillez donc comparer les fonctionnalités qui sont applicables aux deux systèmes (c'est-à-dire que pour Debian, j'utilise uniquement unstable ).


NOTE : Par la gestion des paquets Debian, je fais référence à APT, aptitude et dpkg. Je ne connais pas les outils Arch, donc je ne sais pas s'il y a autre chose que Pacman.
tshepang

Réponses:


7

J'utilise arch régulièrement depuis quelques semaines et ne suis pas expert en la matière donc cette réponse n'est en aucun cas exhaustive, juste quelques points que j'ai notés sur la "flexibilité / puissance":

  • C'est juste une impression mais pacman semble plus moderne et simple dans sa conception / architecture. Au moins, il y a beaucoup moins d'outils à gérer. Bien que je ne connaisse pas le code source d'apt, je viens de regarder le code libalpm (la bibliothèque sous-jacente de pacman) pour créer un patch très simple, et il semble propre et facile à comprendre.

  • Il est également très rapide (en raison de l'optimisation et aussi probablement en se souciant de peu de choses (voir ci-dessous)). La dernière version (pacman 3.5, datant de quelques jours) a tenté d'améliorer les performances en réduisant le nombre de fichiers de base de données impliqués.

  • Bien que arch soit orienté vers l'utilisation de packages binaires, il présente également des avantages lors de la création de packages à partir de la source, avec un système de construction similaire aux ports BSD (ABS).

  • Il est très facile et rapide de créer des paquets, juste quelques lignes dans un fichier PKGBUILD et c'est fait, pas besoin de gérer control / rules / copyright / changelog / quoi que ce soit comme avec les paquets Debian. Et en quelques clics sur une interface web, votre package est partagé avec tout le monde sur AUR (Arch User Repository).

Choses que j'obtiens dans Debian et non dans arch:

  • Déclencheurs / hooks (ce qui permet à apt de mettre à jour le cache d'icônes, le mandb ou quoi que ce soit simplement en regardant où les fichiers d'installation du package, sans que le packager ne fasse quoi que ce soit) (il semble qu'il soit prévu de l'implémenter).

  • debconf (pas grand-chose et en passant en me forçant à faire les choses manuellement ça m'oblige à savoir ce qui est fait exactement) et la bonne gestion des nouveaux fichiers de configuration (j'aimerais au moins que pacman sache quand un fichier de configuration dans un nouveau paquet la version est différente de celle installée car elle a été changée dans la nouvelle version ou parce que je l'ai modifiée localement).

  • signature du package (il semble que cela soit en cours d' élaboration ).

Pour que l'arche soit légère, la seule vraie raison est qu'elle est livrée avec quelques packages installés par défaut et que vous êtes encouragé à ajouter ce dont vous avez besoin.Par conséquent, ne pas installer de dépendances facultatives par défaut incite les utilisateurs à installer pour éviter les ballonnements.


Je ne peux pas analyser ceci: mais je peux m'en passer et je sais d'ailleurs ce que je fais mieux . Il y a aussi une faute de frappe sur la dernière phrase.
tshepang

Dans quelle langue le gestionnaire de paquets pacman est-il écrit? At-il des fonctionnalités de gestion de paquets de bas niveau et de haut niveau similaires à dpkg / apt, et si oui, comment s'appellent-elles?
Faheem Mitha

@Tshepang: désolé, anglophone non natif ici. Je voulais dire "ce n'est pas un gros problème pour moi de ne pas avoir cette fonctionnalité (debconf) et en me forçant à faire les choses manuellement, cela me force à savoir ce qui se fait exactement".
gentledevil

@Faheem Mitha: Pacman est écrit en C, et est une interface avec libalpm, qui gère à la fois la gestion des packages "de haut niveau" et "de bas niveau".
gentledevil

@zanko: Je ne suis pas non plus un locuteur natif. Tout ce que je voulais que vous fassiez, c'est de clarifier la phrase, non pas dans un commentaire, mais sur le post lui-même. BTW, la faute de frappe que j'ai mentionnée est optionnelle . Je pourrais éditer le message moi-même, mais j'ai pensé que vous pourriez aussi bien le corriger avec la partie clarification.
tshepang

6

J'ai commencé mon aventure Linux avec Ubuntu lucid et j'utilise actuellement Arch. J'ai écrit une poignée de paquets Arch, et je dirai que c'est beaucoup plus facile que d'écrire des paquets Debian. Mais, je voudrais souligner à @gentledevil qu'Arch a un système de hooks pour les packages, connu sous le nom de install file.

Fondamentalement, son nom ${pkgname}.installet contient quelques fonctions pour pré / post-installation / suppression / mise à niveau; placez simplement vos mises à jour de font-cache dans cela et ainsi de suite et cela fonctionne à peu près de la même manière que les hooks Debian.

De plus, je remarque que vous avez mentionné «épingler» une application à l'aide des outils de gestion de paquets debian; Le pacman d'Arch a également intégré, /etc/pacman.confaccepte un certain nombre de paramètres, y compris IgnorePkg =, ce qui empêchera les mises à niveau de tous les packages répertoriés après les égaux (délimités par l'espace)


1
De plus, bien que ce ne soit pas un package de dépôt, vous pouvez utiliser le powerpillwrapper pour pacman pour avoir des téléchargements parallèles de plusieurs packages, donc au lieu de pacman -S libfoo libbar libbaztélécharger chaque package l'un après l'autre, il téléchargerait les trois simultanément, augmentant considérablement les vitesses de mise à niveau pour de meilleures connexions.
hanetzer

-1

Avant d'aller trop loin, étudiez la chronologie Pictorial Linux

Pour comprendre les différences dans les gestionnaires de packages, vous devez comprendre les philosophies des OS illustrés ci-dessus


Trois grands parents

  1. Redhat, Now Fedora - Package Manger - RPM, abréviation de Redhat Package Manager, ligne de commande rpm
  2. Slackware - Package Manager - tgz, fichiers zippés ordinaires. Bien que ce ne soient que des fichiers compressés, ils ont été créés par Slackware en amont et placés dans un référentiel, parfois appelé port
  3. Debian - DEB, abréviation de Debian, son outil de ligne de commande est Aptitude or Apt

Ces parents sont mères et pères de la plupart des distributions que nous connaissons aujourd'hui. L'idée / le concept d'un système de gestion de paquets a été dérivé ou partagé sous une forme ou une mode. Quoi qu'il en soit, tous ces parents sont des distributeurs binaires, ce qui signifie qu'un programme est conditionné et décidé par un tiers, puis stocké dans un référentiel, et consommé ou installé par la base d'utilisateurs.

3 parents mineurs

  1. Linux From Scratch - Basé sur la source, pas de gestionnaire de paquets.
  2. Gentoo - Dérivé de Linux à partir de zéro . Cette distribution est essentiellement Linux from Scratch plus un gestionnaire de paquets, appelé Portage / emerge
  3. SourceMage - Gestionnaire de packages Rituel

Ces parents sont mineurs car leur base d'utilisateurs échange la vitesse et la facilité d'installation avec la puissance et la facilité de configuration. Chaque package est téléchargé et compilé à partir de zéro, à l'aide de variables et de fichiers de configuration.

Le pont

Arch a été créé comme un pont entre une distribution binaire, comme l'un des 3 parents majeurs, et une distribution basée sur la source comme l'un des 3 parents mineurs. En tant que tel, il reçoit le statut de parent dans la chronologie, car aucun autre parent n'a fourni cette fonctionnalité. Pacman a la flexibilité de permettre à un utilisateur d'installer un package binaire à partir d'un référentiel officiel ou un package personnalisé à l'aide du système Arch Build. Ce concept offre un équilibre entre la puissance que les parents mineurs donnent et la facilité d'installation que les parents majeurs donnent.


À mon avis, ce n'est pas le gestionnaire de paquets qui montre la puissance d'un système, car tous les gestionnaires de paquets font la même tâche, qui est de gérer et de maintenir un système sain. En tant que tel, le système que vous utilisez doit être déterminé par des facteurs tels que:

  • Niveau utilisateur: quelqu'un qui ne connaît pas Linux devrait commencer par un parent majeur, tandis que quelqu'un techniquement compétent trouvera un équilibre.
  • Ce que vous voulez faire avec votre système: L'exécution d'un serveur LAMP avec des utilisateurs connectés est totalement différente de l'exécution d'un PC de bureau pour la navigation Web et la lecture des e-mails.
  • Niveau de confort: niveau utilisateur nonobstant, si vous êtes techniquement compétent, mais que vous ne voulez pas passer un week-end à compiler un système, vous choisirez un parent majeur, que toutes les personnes que vous connaissez choisissent autre chose.

Ceci est plus axé sur la généologie des distributions, plutôt que sur une comparaison des outils de gestion de paquets de pacman et Debian ...
jasonwryan

@jasonwryan C'est le point, car tous les gestionnaires de packages accomplissent la même tâche, c'est emerge packagename-à- dire la même chose que sudo apt-get install packagename.
eyoung100

À ce niveau, oui; mais cela passe complètement à côté du point de la question, c'est-à-dire ce qui différencie pacman de {apt, aptitude}.
jasonwryan

@jasonwryan J'ai répondu à cela dans la section The Bridge. A part ça, il n'y a pas de différence. Les seules différences sont sémantiques, c'est-à-dire une commande contre une autre. Si l'OP recherche des différences sémantiques, il existe un manuel pour cela.
eyoung100

-3

Ce n'est en aucun cas une réponse complète ou exhaustive - les affiches avant moi ont déjà donné de très bons points, je voudrais juste ajouter mes 2 cents. Autre chose - je ne me suis jamais vraiment habitué à apt / dpkg. Cela m'a toujours semblé trop complexe, je suis vraiment plus à l'aise avec miam / rpm.

pacman est très facile à utiliser, ce qui est un avantage et un inconvénient - vous pouvez apprendre à l'utiliser (construction de packages à part) en un seul après-midi - il utilise principalement des fonctionnalités de gestion de packages intuitives et complètes, mais - et c'est un gros mais - c'est extrêmement rigide.

Si les concepteurs n'avaient pas pensé à une fonctionnalité à l'avance, vous êtes foutu.

Quelques exemples: il n'y a pas de versionnage natif dans pacman. Si vous souhaitez rétrograder une version de package - vous devez télécharger cette version de package particulière et utiliser l'option -U (mise à niveau) pour installer à partir du fichier. Il est très orienté vers l'utilisation de packages de pointe sur votre système.

Il n'y a pas de véritable nettoyage du cache interne / reconstruction complète. Si (en raison d'un problème de réseau) un téléchargement de package a été corrompu, par exemple pendant -Syu, le message d'erreur, bien que précis, ne sera pas très utile - il ne localisera pas le package corrompu même avec une verbosité et un débogage "complets" activés , et aucune quantité de -Syyc ne nettoiera vraiment le cache et ne retéléchargera les packages. La bonne nouvelle est que -Sc vous permettra de savoir où se trouvent les paquets téléchargés afin que vous puissiez simplement supprimer celui qui est incriminé (si vous pouvez déterminer lequel est) ou tous et redémarrer -Syu.

L'intégration de pacman avec dkms est également quelque peu problématique - lors de l'installation d'un nouveau noyau, je continuais à avoir des erreurs de dkms. L'utilisation de dkms build && dkms install contre le nouveau noyau a fonctionné sans accroc, mais pacman n'offrirait aucune information sur la raison pour laquelle dkms a échoué lors de la mise à niveau du noyau (je soupçonne qu'il n'a jamais passé le chemin correct du nouveau noyau, et laisse simplement dkms utiliser la valeur par défaut (en cours d'exécution) noyau mais avec une mauvaise version).

Une autre anecdote sur sa rigidité - comme indiqué, j'ai l'habitude du rpm / yum. Si j'ai un fichier sur mon système et que je souhaite savoir quel paquet le possède, je peux exécuter yum provides / path / to / file et obtenir TOUS les paquets qui peuvent le mettre là-bas - même si aucun d'eux n'est installé. Si le fichier a été placé manuellement, et maintenant je souhaite installer un package - il renommera le nouveau (ajoutez l'extension .rpmnew), et laissez-moi choisir ce que j'utilise.

pacman indique simplement qu'un fichier existe déjà, mais avec un message d'erreur complètement hors de propos - il se plaint de conflits entre le "vrai" propriétaire du fichier et le package "filesystems" actuellement installé, comme s'il était également propriétaire du même fichier. De plus, il est principalement axé sur les informations installées localement - essayer d'obtenir des informations (telles que les listes de fichiers et la propriété) des packages non encore installés est moins intuitif.

Autrement dit - il n'est pas aussi mature que miam, et probablement dpkg, ce qui se prête à sa facilité d'utilisation ainsi qu'à sa relative rigidité.


1
À moins d'une non-réponse complète, vous soulevez un certain nombre de points qui sont vraiment le produit d'une méconnaissance de pacman. Par exemple pacman -Qo $file, vous dira quel paquet possède $ file. De plus, toute votre réponse est un homme de paille, car l'OP a explicitement demandé des différences entre Arch et Debian - yumn'a rien à voir avec cela ...
jasonwryan

c'est pourquoi j'ai explicitement divulgué ce fait au début de ma réponse. comme pour le fichier -Qo $ - avez-vous déjà essayé cela pour un paquet pas encore installé?
Dani_l

Il est inutile de l'essayer pour un package non installé; il existe d'autres outils pour cela. Et la divulgation n'atténue pas le fait que vous n'avez pas répondu à la question: une "comparaison" entre yum et pacman n'est pas la même que les différences entre les gestionnaires de paquets de Debian et d'Arch.
jasonwryan

@jasonwryan Bien sûr, il y a un point. Ce n'est pas parce que vous ne voyez pas la nécessité de savoir quel package peut posséder un fichier même s'il n'est pas encore installé. C'était ça le point. Quant aux autres outils - ont-ils besoin de savoir? pacman est le gestionnaire de paquets. En ce qui concerne votre point principal - j'ai peut-être complètement mal lu la question, mais j'ai supposé qu'il s'agissait d'un PM léger par rapport à un PM plus complexe. Je suppose que apt / dpkg est au moins aussi complexe que yum / rpm, en ce qui concerne les fonctionnalités.
Dani_l

Mon point est que vous répondez à une question sur la comparaison des pommes avec des oranges en comparant votre compréhension limitée des pommes avec des poires. Et oui, vous avez complètement mal lu la question ...
jasonwryan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.