L'ingegnere quantistico Seth Lloyd è convinto che l'universo sia un gigantesco computer. Speriamo non faccia girare Windows.

— Kevin Kelly

Confronto tra package manager ?

  • user warning: Table './stenoweb/node_comment_statistics' is marked as crashed and should be repaired query: SELECT last_comment_timestamp, last_comment_name, comment_count FROM node_comment_statistics WHERE nid = 176 in /home/stenoweb/public_html/modules/comment/comment.module on line 596.
  • user warning: Table './stenoweb/node_comment_statistics' is marked as crashed and should be repaired query: SELECT last_comment_timestamp, last_comment_name, comment_count FROM node_comment_statistics WHERE nid = 19 in /home/stenoweb/public_html/modules/comment/comment.module on line 596.
  • user warning: Table './stenoweb/node_comment_statistics' is marked as crashed and should be repaired query: SELECT comment_count FROM node_comment_statistics WHERE nid = 19 in /home/stenoweb/public_html/modules/comment/comment.module on line 1121.
http://www.stenoweb.it/files/blog/daditux.png E' difficile fare un confronto sereno tra package managers, tuttavia spesso si fa un po' di confusione, e quindi mi pare “simpatico” fare due chiacchiere su DPKG, APT e soci, per vedere come si collocano in rapporto ad altri strumenti analoghi, specie per quanto riguarda lo storico RPM creato da RedHat. Non so voi, ma per me è stato impossibile avere delle opinioni “superpartes”, è un po' come, rimanendo in ambito pinguinesco, chiedere se è meglio GNOME o KDE. Infatti quando si chiede a qualcuno quale sia il loro gestore di pacchetti preferito e perché, si ottengono sempre risposte uguali sia da una parte che dall'altra. Bisognerebbe a volte ammettere la propria ignoranza in merito, altrimenti la scelta pare più una questione di fede che altro. Va bé, l'unico modo è provarli e farsi delle personali e in quanto tali opinabili idee.

Partiamo dal fatto che la gestione dei pacchetti sembra comprendere tre aspetti: il formato specifico dei pacchetti (deb, rpm), i comandi di gestione degli stessi (dpkg, rpm) e l' interfaccia di gestione avanzata (apt, yum).
I sostenitori di Debian naturalmente dicono che la loro distro preferita eccelle in ogni campo, ma la stessa risposta si ottiene dall'altra parte e quindi torniamo sempre ad un punto morto.
Allora vediamo (senza andare troppo nei dettagli) un po' i tre aspetti menzionati.

Formato pacchetti

La base è il formato dei pacchetti, ed entrambe prevedono un sacco di funzionalità. Flamewars sono state scatenate in cui ognuno getta discredito sull'altra. Ad esempio una credenza molto diffusa tra i sostenitori del formato DEB è che il loro formato sia nettamente superiore a RPM, cosa, ahimè, semplicemente falsa. In realtà il formato RPM è più ricco di funzionalità rispetto al DEB, ma questi “plus” sono usati talmente di rado che quasi non se ne fa caso. Ad esempio il formato RPM ha il concetto di “trigger”, che abilita un pacchetto a registrare delle determinate azioni da compiere se un altro pacchetto viene modificato o aggiornato. Oppure il fatto di permettere che le dipendenze vengano soddisfatte da file residenti sul filesystem locale, anche se magari questa procedura è un po' un boomerang dal momento che spesso scatena il “dependency hell” che chiunque nella sua vita ha almeno sperimentato una volta se ha avuto a che fare con le distribuzioni di derivazione RedHat.

Comandi di gestione

La situazione per quanto riguarda gli strumenti di gestione dei pacchetti non è così diversa. Entrambi (dpkg e rpm) forniscono più o meno le stesse funzionalità: installazione e rimozione (ignorando o meno le dipendenze), interrogazione, visualizzazione e così via. Quindi nonostante il formato dei binari sia diverso, le funzionalità spesso sono equivalenti.

Vediamo una semplice tabella:


dpkg rpm
dpkg --info rpm -qpi
dpkg --contents rpm -qpl
dpkg --install rpm -i
dpkg --list rpm -qa
dpkg --listfiles rpm -ql
dpkg --search rpm -qf
dpkg --status rpm -qi
dpkg --remove n/a
dpkg --purge rpm -E
dpkg --install --force-depends rpm -i --nodeps
dpkg --install --force-overwrite rpm -i --replacefiles

Interfaccia di gestione

La terza componente di un sistema di gestione dei pacchetti è il tool ad alto livello (che si basa sul gestore visto prima e sul formato dei pacchetti) che ha lo scopo di dare uno strumento in grado di semplificare l'installazione e la gestione degli aggiornamenti. Qui, senza dubbio, apt di Debian ha goduto per molto tempo di funzionalità senza rivali rispetto ad altre distribuzioni, che però non sono rimaste ferme al palo: oggi ad esempio yum (o anche urpmi di Mandriva) forniscono oramai funzionalità simili, anche se a mio parere la velocità e la sicurezza paiono ancora far pendere il piatto della bilancia in favore di apt. Ma gli altri stanno arrivando, e probabilmente tra non molto anche questo vantaggio si assottiglierà fino a scomparire.
Anche qui dunque vediamo una tabella che confronta apt, yum e urpmi.

Attenzione: la tabella è “apt-centrica” e quindi destinata ad essere presa come libero riferimento, non è certo destinata a far emergere funzionalità esclusive di apt che gli altri tools non hanno (sicuramente ne hanno a loro volta di esclusivi a cui non esiste un corrispondente apt).

Magari è utile se “saltate” da una distribuzione ad un altra per trovare il comando opportuno da dare. Non prendetela come oro colato, è probabile che questa tabella abbia anche bisogno di una “rinfrescata”.

APT yum urpmi
apt-cache search yum search urpmq
apt-cache show yum info urpmq -i
apt-cache showpkg n/a n/a
apt-cache depends n/a n/a
apt-cache rdepends n/a n/a
apt-get install yum install urpmi
apt-get install –download-only yum --download-only n/a
apt-get remove n/a n/a
apt-get remove --purge yum remove urpme
apt-get update n/a urpmi.update -a
apt-get upgrade yum update n/a
apt-get dist-upgrade yum --obsoletes urpmi --auto-select
apt-get source n/a n/a
apt-get build-dep n/a n/a
apt-file search yum provides urpmf

E allora cosa ne ricaviamo?

Mah! Personalmente confrontando i sistemi di gestione dei pacchetti attraverso varie distribuzioni di Linux, raggiungo la conclusione che tutti i principali attori del settore sono semplici e fallibili... mortali. Un unico formato condito da una interfaccia unica di gestione sarebbe veramente gradito nel futuro (almeno a me).

Ma poi, fatemelo dire, considerare APT la vera forza di distribuzioni come Debian è sbagliato e riduttivo. I veri motivi del suo successo (e di riflesso in parte anche della pletora di distribuzioni che derivano da essa) sono altri, e ben lontani da qualunque interfaccia utente.

Meno visibili e molto più profondi, ma anche qui molti non sarebbero d'accordo.

Beh, apt si può usare anche come frontend per rpm.

Poi sono rare le volte in cui ci si trova davvero a sfruttare le possibilità offerte dai sistemi di pacchettizzazione.
In generale direi che si sfrutta davvero il tutto solo quando si fa pulizia o si deve riparare a qualche guaio, e qui l'unico sistema che ho trovato davvero robusto in questi casi è portage con emerge (che però è molto facile da confondere se non si seguono bene le linee guida per il mantenimento).

Purtroppo gli sviluppatori di Gentoo sono dei pazzi scatenati e combinano una sciocchezza bella grossa circa ogni sei mesi, quindi purtroppo la distro non è più affidabile da un paio d'anni.

È vero che questo post è un appunto per chi passa da una distro all'altra.

Grazie GiRa ho scoperto di essere fortunatissimo!!!

Sono 2 anni che uso la stessa gentoo aggiornata continuamente trasportata dal pensionato athlon-xp al pentium2core ricompilando il kernel e tutti i pacchetti (n.813) .... non è esploso ancora niente.

Che sia ostica è sacrosantamente vero!!!
Ma anche molto potente versatile stabile (certo in "x86" e basta)

Perchè l'avete tutti con sta distro?

Scusate corro a giocare al lotto

epperò APT permette una gestione *molto* raffinata delle singole dipendenze di un pacchetto, dei repositories, ecc... Basti pensare al pinning e al fatto di poter far convivere diversi branch sulla stessa installazione, addirittura diverse architetture.

Oltretutto storicamente, correggetemi se sbaglio, RPM è nato *dopo* DEB ;-)

E' vero, DEB (e dpkg) nasce prima (anche se di poco) di RPM.
La vera differenza poi però la ha fatta APT. A debian serviva un modo rapido, pratico ed efficiente per installare i programmi, che gestisse automaticamente le dipendenze e che avesse cura di mantenere i file di configurazione esistenti mentre si effettuavano i vari aggiornamenti. Quello che poi è avvenuto anche con il successivo (e questa volta di molto) YUM.

E vero anche che APT può essere usato come frontend per i pacchetti RPM (mi pare ad esempio il caso di PCLinuxOS) e questo per accrescere un po' ancora la confusione ... :D
Certo è che un RPM per openSuse non è che vada a meraviglia con Fedora o viceversa.

Per quanto riguarda "il resto del mondo" posso parlare solo di pacman di arch che riunisce in un solo strumento il "dualismo" dpkg/apt e rpm/yum. Molto semplice ed efficace (specie la crezione dei pacchetti) anche se non certo con la versatilità dei big.

Il succo comunque non cambia, ogni gestore di pacchetti o formato (parlo soprattutto di chi li crea i pacchetti) esegue i suo compito se usato con capacità e può causare disastri nell'altro caso.

Scusa ma:
> Sono 2 anni che uso la stessa gentoo aggiornata continuamente trasportata
> dal pensionato athlon-xp al pentium2core ricompilando il kernel e
> tutti i pacchetti (n.813) .... non è esploso ancora niente.

È proprio quello che dicevo che ha di strafigo portage.
Riesci a fare di tutto e ne esci sempre.

Il problema di Gentoo sono i conflitti interni, ed è vero che un paio di volte all'anno dan dei "colpi di matto" considerevoli.

L'ho usata per un bel po' di anni prima che prendesse questa piega.