Une discussion de ce message ma rendu curieux des différences entre la gestion des paquets Debian et Arch. De plus, les gens ont tendance à dire quArch est très léger, alors je me demande ce que cela a à voir avec la gestion des paquets. Est-ce peut-être parce que Debian traite Recommande comme des dépendances dures par défaut?
Pouvez-vous également mentionner la flexibilité / puissance entre les deux gestionnaires de paquets: lequel des deux vous permet den 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, étant donné quArch a une seule suite et Debian en a plusieurs (par exemple, lépinglage APT et la gestion avancée des dépendances viennent à lesprit ), veuillez donc comparer les fonctionnalités applicables aux deux systèmes (cest-à-dire supposer que pour Debian, je nutilise que unstable ).
Commentaires
- REMARQUE : Par la gestion des paquets Debian, je ‘ fait référence à APT, aptitude et dpkg. I ‘ ne connaissant pas les outils Arch, je ne ‘ pas savoir sil y a ‘ autre chose que Pacman.
Réponse
Jutilise juste arch régulièrement depuis quelques semaines et je ne suis pas un expert sur le sujet donc cette réponse nest en aucun cas exhaustive, juste quelques points que jai notés sur la « flexibilité / puissance »:
-
Ceci est juste une impression mais pacman semble plus moderne et simple dans sa conception / architecture. Au moins, il y a beaucoup moins doutils à gérer. Bien que je ne connaisse pas le code source dapt, il mest arrivé de regarder le code libalpm (la bibliothèque sous-jacente de pacman) pour créer un correctif très simple, et il semble clair et facile à comprendre.
-
Il est également très rapide (grâce à loptimisation et aussi probablement en se souciant de peu de choses (voir ci-dessous)). La dernière version (pacman 3.5, vieille de quelques jours) a essayé daméliorer les performances en réduisant le nombre de fichiers de base de données impliqués.
-
Alors que arch est orienté vers lutilisation de paquets binaires, il présente également des avantages lors de la construction de paquets à partir des sources, avec un système de construction similaire aux ports de BSD ( ABS).
-
Il est très facile et rapide de créer des paquets, juste quelques lignes dans un fichier PKGBUILD et cest fait, pas besoin de gérer le contrôle / les règles / le copyright / changelog / comme avec les paquets Debian. Et en quelques clics sur une interface Web, votre paquet est partagé avec tout le monde sur AUR (Arch User Repository).
Ce que je reçois dans Debian et pas dans arch:
-
Triggers / h ooks (ce qui fait quapt met à jour le cache dicônes, le mandb ou autre chose simplement en regardant où le paquet installe les fichiers, sans que le packager nait besoin de faire quoi que ce soit) (il semble quil y ait prévoit de mettre en œuvre ceci).
-
debconf (pas grand-chose et dailleurs en me forçant à faire les choses manuellement, cela moblige à savoir ce qui est fait exactement) et une gestion correcte des nouveaux fichiers de configuration (jaimerais au moins que pacman sache quand un fichier de configuration dans une nouvelle version de package est différent de celui installé car il a été modifié dans la nouvelle version ou parce que je lai modifié localement).
-
signature du paquet (il semble que cela soit travaillé ).
Pour Arch étant léger, la seule vraie raison est quil est livré avec quelques paquets installés par défaut et vous êtes encouragé à ajouter ce dont vous avez juste besoin, donc probablement ne pas installer de dépendances optionnelles par défaut incite les utilisateurs à installer pour éviter le gonflement .
Commentaires
- Je peux ‘ analyser ceci: mais je peux men passer et savoir ce que je fais de mieux . Il y a aussi une faute de frappe sur la dernière phrase.
- 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 sappellent-elles?
- @Tshepang: désolé, anglophone non natif ici. Je voulais dire » ce nest pas un gros problème pour moi de ne pas avoir cette fonctionnalité (debconf) et en me forçant à faire les choses manuellement cela moblige à savoir ce qui est exactement fait « .
- @Faheem Mitha: Pacman est écrit en C, et est une interface vers libalpm, qui gère à la fois » haut -level » et » bas niveau » gestion des paquets.
- @zanko: Je ‘ ne suis pas non plus un locuteur natif. Tout ce que je voulais que vous fassiez, cest de rendre la phrase plus claire, non pas dans un commentaire, mais sur le message lui-même. BTW, la faute de frappe que jai mentionnée est optionnelle . Je pourrais modifier le message moi-même, mais jai pensé que vous pourriez aussi bien le corriger avec la partie clarification.
Réponse
Jai commencé mon aventure Linux avec Ubuntu lucid et jutilise actuellement Arch.Jai écrit une poignée de paquets Arch, et je dirai que cest beaucoup plus facile que d écrire des paquets Debian. Mais, je voudrais signaler à @gentledevil quArch a un système de hooks pour les paquets, connu sous le nom de install file
.
Fondamentalement, il sappelle ${pkgname}.install
, et contient quelques fonctions pour pré / post installation / suppression / mise à niveau; placez simplement vos mises à jour du cache de polices dans cela et ainsi de suite et cela fonctionne à peu près de la même manière que les hooks Debian.
De plus, jai remarqué que vous avez mentionné « épingler » une application à laide des outils de gestion de paquets Debian; le pacman dArch a cela intégré de même, /etc/pacman.conf
accepte un certain nombre de paramètres, y compris IgnorePkg =
, ce qui empêchera les mises à niveau de tout paquet répertorié après légal (délimité par des espaces )
Commentaires
- De plus, même sil ne sagit pas dun package de dépôt, vous pouvez utiliser le wrapper
powerpill
pour pacman davoir des téléchargements parallèles de plusieurs packages, donc au lieu depacman -S libfoo libbar libbaz
télécharger chaque package un après lautre r il téléchargerait les trois simultanément, augmentant considérablement les vitesses de mise à niveau pour de meilleures connexions.
Réponse
Avant I allez trop loin, étudiez la Chronologie picturale de Linux
Pour comprendre les différences entre les gestionnaires de packages, vous devez comprendre les philosophies du système dexploitation » es illustré ci-dessus
Trois grands parents
- Redhat, Now Fedora – Package Manager – RPM, abréviation de Redhat Package Manager, ligne de commande
rpm
- Slackware – Package Manager – tgz, fichiers zippés ordinaires. Bien quil ne sagisse que de fichiers compressés, ils ont été construits par Slackware en amont et placés dans un référentiel, parfois appelé port
- Debian – DEB, abréviation de Debian, son outil de ligne de commande est
Aptitude or Apt
Ces parents sont les mères et les pères de la plupart des distributions que nous connaissons aujourdhui. Lidée / le concept dun système de gestion de paquets a été dérivé ou partagé dans certains Quoi quil en soit, tous ces parents sont des distributeurs binaires, ce qui signifie quun programme est emballé et décidé par un tiers, puis stocké dans un référentiel, et consommé ou installé par la base dutilisateurs.
3 Parents mineurs
- Linux From Scratch – Basé sur la source, pas de gestionnaire de paquet.
- Gentoo – Dérivé de Linux from Scratch . Cette distribution est essentiellement Linux from Scratch plus un gestionnaire de paquets, appelé Portage / emerge
- SourceMage – Package Manager Sorcery
Ces parents sont mineurs parce que leur base dutilisateurstroque la rapidité et la facilité dinstallation avec la puissance et la facilité de configuration. Chaque paquet est téléchargé et compilé à partir de zéro, en utilisant des variables et des fichiers de configuration.
The Bridge
Arch a été créé comme un pont entre une distribution binaire, comme lun des 3 principaux parents, et une distribution basée sur la source comme lun des 3 parents mineurs. En tant que tel, il reçoit le statut de parent dans la chronologie, car aucun autre parent na fourni cette fonctionnalité. Pacman a la flexibilité de permettre à un utilisateur dinstaller un package binaire à partir dun référentiel officiel, ou un package personnalisé à laide du système Arch Build. Ce concept offre un équilibre entre le pouvoir des parents mineurs et la facilité dinstallation que donnent les parents majeurs.
À mon avis, ce nest pas le gestionnaire de paquets qui montre la puissance dun système, car tous les gestionnaires de packages effectuent la même tâche, à savoir gérer et 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 d’utilisateur: Quelquun Les nouveaux utilisateurs de Linux devraient commencer par un parent majeur, alors quune personne techniquement compétente trouvera un équilibre.
- Ce que vous voulez faire avec votre système: exécuter un serveur LAMP avec des utilisateurs connectés est totalement différent de faire fonctionner un ordinateur de bureau pour la navigation sur le Web et la lecture des e-mails.
- Niveau de confort: niveau d’utilisateur non respecté, 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, peu importe si tout le monde que vous connaissez choisit autre chose.
Commentaires
- Ceci est plus focalisé utilisé sur la généologie des distributions, plutôt que sur une comparaison des outils de gestion de paquets de pacman et Debian ‘ …
- @jasonwryan Que ‘ est le point, car tous les gestionnaires de packages accomplissent la même tâche, cest-à-dire que
emerge packagename
est identique àsudo apt-get install packagename
. - À ce niveau, oui; mais cela manque complètement le point de la question, cest-à-dire ce qui différencie pacman de {apt, aptitude}.
- @jasonwryan Jai répondu à cela dans la section The Bridge. A part ça, il ny a pas de différence. Les seules différences sont sémantiques, cest-à-dire une commande par rapport à une autre.Si lOP recherche des différences sémantiques, il existe un manuel pour cela.
Réponse
Cest par non signifie une réponse complète ou exhaustive – les affiches devant moi ont déjà donné de très bons points, je voudrais juste ajouter mes 2 centimes. Autre chose – je ne me suis jamais vraiment habitué à apt / dpkg. Cela a toujours semblé trop complexe pour moi, je suis vraiment plus à laise avec yum / rpm.
pacman est très facile à utiliser, ce qui est un avantage et un inconvénient – vous pouvez apprendre à lutiliser (construction de paquets à part) en un seul après-midi – il utilise principalement des fonctionnalités de gestion de paquets intuitives et complètes, mais – et cest un gros mais – il est extrêmement rigide.
Si les concepteurs nont pas pensé à une fonctionnalité au préalable, vous êtes foutu.
Quelques exemples: il ny a pas de version native dans pacman. Si vous souhaitez rétrograder une version de package, vous devez télécharger cette version de package en particulier et utiliser loption -U (mise à niveau) pour installer à partir du fichier. est très orienté vers alwa ys en utilisant des packages de pointe sur votre système.
Il ny a pas de véritable nettoyage du cache interne / reconstruction complète. Si (en raison dun problème de réseau) un téléchargement de paquet a été corrompu, par exemple pendant -Syu, le message derreur, bien que précis, ne sera pas dune grande utilité – il ne localisera pas le paquet corrompu même avec la verbosité «complète» et le débogage activés , et aucune quantité de -Syyc ne nettoiera vraiment le cache et ne retéléchargera les paquets. La bonne nouvelle est que -Sc vous indiquera où se trouvent les paquets téléchargés afin que vous puissiez simplement supprimer le paquet incriminé (si vous pouvez déterminer lequel est) ou tous et redémarrer -Syu.
Lintégration de pacman avec dkms est également quelque peu problématique – lors de linstallation dun nouveau noyau, jai continué à avoir des erreurs de dkms. Lutilisation de dkms build & & dkms install contre le nouveau noyau fonctionnait sans accroc, mais pacman noffrait aucune information sur les raisons pour lesquelles dkms a échoué pendant le mise à jour du noyau (je soupçonne quil na jamais passé le chemin correct du nouveau noyau, et laissez simplement dkms utiliser le noyau par défaut (en cours dexécution) mais avec une mauvaise version).
Une autre anecdote à propos de son inflexibilité – comme déclaré, je suis habitué à rpm / yum. Si jai un fichier sur mon système et que je souhaite savoir quel paquet le possède, je peux exécuter yum fournit / path / to / file et obtenir TOUS les paquets qui peuvent le mettre là – même si aucun dentre eux nest installé. Si le fichier a été placé manuellement, et maintenant je souhaite installer un paquet – il renomme le nouveau (ajoutez lextension .rpmnew), et laissez-moi choisir quoi utiliser.
pacman se trompe simplement quun fichier est déjà existe, mais avec un message derreur totalement non pertinent – il se plaint de conflits entre le « vrai » propriétaire du fichier et le paquet « systèmes de fichiers » actuellement installé, comme sil était également propriétaire du même fichier. En outre, il est principalement orienté vers les informations installées localement – essayer dobtenir des informations (telles que les listes de fichiers et la propriété) des paquets non encore installés est moins intuitif.
En termes simples, ce nest pas aussi mature que miam, et probablement dpkg, ce qui lui confère également une facilité dutilisation est une relative rigidité.
Commentaires
- À court de non-réponse complète, il y a un certain nombre de points que vous soulevez qui sont vraiment le produit dune 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 lOP a explicitement demandé les différences entre Arch et Debian –yum
na rien à voir avec cela … - cest pourquoi jai 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é?
- Il ne sert à rien de lessayer pour un paquet non installé; il existe dautres outils pour cela. Et la divulgation ne ‘ t atténue pas le fait que vous navez ‘ pas répondu à la question: a » la comparaison » entre yum et pacman nest pas identique aux différences entre Debian ‘ et Arch ‘ gestionnaires de paquets.
- @jasonwryan Bien sûr, il y a un point. Tout simplement parce que vous ‘ ne voyez pas la nécessité de déterminer quel paquet pourrait posséder un fichier même sil ‘ nest pas encore installé, nest-ce pas ‘ t signifie quun tel besoin nexiste pas ‘. Cétait le point. Quant aux autres outils, sont-ils sur la base du besoin de savoir? pacman est le gestionnaire de paquets. En ce qui concerne votre point principal – jai peut-être complètement mal interprété la question, mais jai supposé quil sagissait dun PM léger par rapport à un PM plus complexe. Je suppose que apt / dpkg est au moins aussi complexe que yum / rpm, du point de vue des fonctionnalités.
- Ce que je veux dire, cest 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 …