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

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 ).

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.

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)

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.

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é.