Da apt a dnf: comandi equivalenti per Rocky e Fedora

La risposta breve

Passare da apt a dnf è soprattutto un cambiamento di terminologia. apt install nginx diventa dnf install nginx. apt remove nginx diventa dnf remove nginx. apt update non ha un equivalente diretto, perché dnf aggiorna autonomamente i metadati dei repository quando la copia nella cache diventa obsoleta. La parte semplice della conversione occupa una sola schermata. La parte utile riguarda le quattro operazioni che non hanno una corrispondenza diretta: aggiungere un repository, annullare una transazione, installare un gruppo di pacchetti ed eseguire aggiornamenti non interattivi.

Tutti i comandi riportati di seguito sono pensati per essere eseguiti sul proprio server. Leggere il riepilogo della transazione visualizzato da dnf prima di rispondere a y, soprattutto quando sono previste rimozioni.

Quali distribuzioni usano dnf e quali usano apt

dnf è il gestore dei pacchetti di Fedora, di Red Hat Enterprise Linux (RHEL) e delle ricostruzioni di RHEL: Rocky Linux, AlmaLinux e CentOS Stream. apt è il gestore dei pacchetti di Debian e di tutte le distribuzioni derivate da Debian, che su un VPS significa quasi sempre Ubuntu. Non esiste una terza possibilità. Se l'elenco delle immagini del provider offre Rocky Linux o AlmaLinux, userai dnf. Se offre Ubuntu, userai apt. Il motivo per cui uno dei due rami usa quattro nomi per indicare sistemi in gran parte uguali è una storia che conviene conoscere prima di scegliere tra le due opzioni; come Red Hat Linux è diventato Fedora, RHEL, CentOS, Rocky e AlmaLinux spiega l'origine di ciascuna distribuzione.

Il formato dei pacchetti dipende dallo strumento. dnf installa file .rpm e il relativo database è rpm. apt installa file .deb e il relativo database è dpkg. Per questo molte pagine di installazione dei fornitori hanno una scheda per ciascuna famiglia e un file .deb scaricato dalla pagina delle release di un progetto è inutilizzabile su Rocky Linux.

Indipendentemente dalla famiglia scelta, il primo accesso richiede gli stessi interventi. I primi dieci minuti su un nuovo VPS si applicano a entrambe. Cambia soltanto il comando di installazione.

Ogni comando apt e il relativo equivalente dnf

Installare, rimuovere, cercare e visualizzare. In entrambi i casi si usano quasi le stesse parole.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show è dnf info. È l'unico verbo rinominato del gruppo, ma c'è una differenza di comportamento che spesso causa errori. dnf remove rimuove anche le dipendenze che non servono più a nessun altro pacchetto, mentre apt remove le lascia installate per un successivo apt autoremove. Di conseguenza, rimuovere una piccola utility su Rocky Linux può proporre la rimozione di una dozzina di librerie. Leggere l'elenco prima di confermare.

Aggiornare i metadati, verificare cosa è in attesa e aggiornare i pacchetti.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update è obbligatorio con apt, perché apt usa i metadati presenti sul disco e installa senza problemi una versione che può essere stata rimossa dall'archivio mesi prima. dnf controlla l'età della cache prima di ogni transazione e scarica automaticamente metadati aggiornati, quindi sudo dnf makecache serve soltanto per forzare il download immediato invece di rimandarlo alla prossima installazione.

apt distingue l'aggiornamento completo del sistema in due modalità, mentre dnf non lo fa. apt upgrade rifiuta di rimuovere qualsiasi pacchetto installato, quindi si interrompe quando un aggiornamento richiede la rimozione di un pacchetto. apt full-upgrade è la versione autorizzata a rimuovere pacchetti. dnf non ha questa limitazione, quindi dnf upgrade è l'equivalente di apt full-upgrade, non di apt upgrade. dnf update è un alias precedente dello stesso comando e funziona ancora.

Un dettaglio è importante quando si automatizza questa operazione: dnf check-update termina con lo stato 100 quando sono disponibili aggiornamenti e con 0 quando non ce ne sono. apt list --upgradable termina con 0 in entrambi i casi, quindi gli script devono analizzarne l'output.

Elencare i pacchetti installati e verificare quale pacchetto contiene un file.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

L'ultima riga di ciascun blocco risponde a una domanda diversa da quelle precedenti. dpkg -S e rpm -qf cercano soltanto nei pacchetti già installati, quindi rispondono alla domanda «quale pacchetto ha installato questo file». apt-file search e dnf provides cercano nei repository, quindi rispondono alla domanda «quale pacchetto dovrei installare per ottenere questo file». apt-file è un pacchetto separato su Ubuntu e richiede sudo apt-file update prima del primo utilizzo. dnf provides non richiede nulla di aggiuntivo, anche se il primo utilizzo può essere lento perché dnf scarica gli elenchi dei file dei repository per eseguire la ricerca.

Per elencare i file contenuti in un pacchetto non ancora installato, usare dnf repoquery -l nginx. Con apt il comando è apt-file list nginx.

Rimuovere automaticamente le dipendenze inutilizzate, pulire la cache e bloccare una versione.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock non è installato per impostazione predefinita su Rocky Linux o AlmaLinux, quindi la prima di queste righe termina con No such command: versionlock su un sistema appena installato. Installarlo prima con sudo dnf install python3-dnf-plugin-versionlock. apt non richiede componenti aggiuntivi per apt-mark hold, perché il blocco è uno stato di dpkg e non un plugin.

Dove si interrompe la corrispondenza: aggiungere un repository

Questa è la parte che induce gli amministratori Ubuntu a cercare un comando inesistente. In dnf non esiste alcun add-apt-repository e non esistono archivi personali di pacchetti (PPA). Un PPA è un servizio gestito da Launchpad, e Launchpad fa parte dell'infrastruttura Ubuntu. Nell'ecosistema RPM non esiste un servizio equivalente che li ospiti.

dnf usa invece un file di testo semplice per ogni repository in /etc/yum.repos.d/, con estensione .repo.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever e $basearch sono variabili di dnf. dnf inserisce automaticamente il numero della release principale e l'architettura della CPU in fase di esecuzione. Lo stesso file funziona quindi con la versione 9 e la versione 10, oltre che con x86_64 e aarch64.

La maggior parte dei vendor pubblica questo file e indica di scaricarlo. Le istruzioni ufficiali di Docker per RHEL e i relativi rebuild prevedono due comandi:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

La prima riga è necessaria perché config-manager è un plugin, non una parte di dnf. Se la si omette, la seconda riga restituisce No such command: config-manager. Nulla impedisce di scaricare manualmente lo stesso file .repo con curl e salvarlo in /etc/yum.repos.d/; il risultato è identico. Installare Docker su un VPS descrive lo stesso passaggio sul lato Debian, dove l'operazione equivalente scrive un elenco di sorgenti e una chiave di firma in due directory diverse.

La differenza nella struttura determina dove cercare quando un repository presenta problemi. apt conserva le definizioni in /etc/apt/sources.list e /etc/apt/sources.list.d/, mentre le chiavi di firma si trovano separatamente in /etc/apt/keyrings/. dnf conserva tutto in /etc/yum.repos.d/ e la chiave è un URL all'interno del file .repo. Di conseguenza, c'è un solo file da leggere e un solo file da eliminare. Le versioni più recenti di apt si sono avvicinate alla stessa struttura con il formato deb822, usando un file .sources per ogni repository. Se hai già incontrato l'errore delle sorgenti duplicate deb822 su Ubuntu, hai già visto la metà del problema relativa ad apt.

EPEL è l'archivio che la maggior parte delle guide dà per già configurato

Extra Packages for Enterprise Linux (EPEL) è un progetto Fedora che prepara pacchetti Fedora per RHEL e le relative distribuzioni derivate. È la soluzione più vicina a una PPA universale disponibile in questo ecosistema e moltissime guide presumono che sia già abilitata. Se dnf install restituisce No match for argument per un pacchetto disponibile sul sito ufficiale del progetto, EPEL è la prima cosa da controllare.

Su Rocky Linux e AlmaLinux:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB è CodeReady Builder, un repository di librerie distribuito insieme al sistema ma non abilitato per impostazione predefinita. La maggior parte dei pacchetti EPEL dipende da un elemento presente in questo repository. Per questo, abilitare EPEL senza CRB non genera necessariamente un errore immediato. L'errore si verifica in seguito, durante l'installazione, con dipendenze irrisolte verso un pacchetto che non avete mai visto. Abilitate prima CRB: questo tipo di errore scompare.

Su RHEL, CRB viene reso disponibile tramite la sottoscrizione e non tramite config-manager. Per questo passaggio, seguite le istruzioni ufficiali di Red Hat per EPEL. Fedora non richiede nulla di tutto ciò, perché il repository principale contiene già i pacchetti che EPEL retroporta. La policy di EPEL prevede di non sostituire mai un pacchetto distribuito da RHEL. L'aggiunta del repository non modifica quindi nulla di ciò che è già installato sul server.

dnf history undo, la funzione che apt non offre

dnf registra ogni transazione e può costruirne l’inverso.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history stampa un elenco numerato delle transazioni, con la riga di comando che ha avviato ciascuna di esse. undo costruisce la transazione opposta: i pacchetti installati da quella transazione vengono rimossi e quelli aggiornati tornano alla versione precedente. È la funzione che manca di più agli utenti di apt dopo il passaggio a dnf.

Ha limiti concreti, che è importante conoscere prima di farvi affidamento. undo può reinstallare una versione del pacchetto solo se questa esiste ancora in un repository abilitato. Se la versione precedente è stata rimossa dal mirror, l’annullamento fallisce con un errore di pacchetto non trovato. Il rollback si ferma inoltre al database dei pacchetti. Un file di configurazione riscritto dall’aggiornamento resta riscritto e lo schema di un database migrato dal servizio al primo avvio resta migrato. dnf ripristina i file. Non ripristina i dati.

apt non ha un equivalente. /var/log/apt/history.log registra esattamente ciò che è accaduto, inclusa la riga di comando, ma leggere un log non annulla l’operazione. Con apt il ripristino è manuale: esegui apt list -a nginx per verificare quali versioni sono ancora disponibili nell’archivio, quindi sudo apt install nginx=<exact version string> per bloccarne una e aggiungi sudo apt-mark hold nginx affinché il prossimo aggiornamento non annulli la correzione.

I gruppi di pacchetti non hanno un equivalente in apt

dnf può installare in un unico comando un insieme di pacchetti identificato da un nome.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

Le guide meno recenti usano dnf groupinstall "Development Tools". Questo alias funziona con dnf 4, ma è stato rimosso in dnf 5. Pertanto, dnf group install, composto da due parole, è l'unica forma compatibile con entrambe le versioni. Usate questa forma senza altre considerazioni.

apt non gestisce i gruppi. Il concetto più vicino in Debian è un metapacchetto: un pacchetto altrimenti vuoto, il cui unico contenuto è un elenco di dipendenze, ad esempio build-essential. La differenza pratica emerge durante la rimozione: rimuovendo un metapacchetto, le relative dipendenze restano installate finché non eseguite apt autoremove, mentre dnf group remove rimuove i pacchetti del gruppo nella stessa transazione.

unattended-upgrades e dnf-automatic

Entrambe le famiglie consentono di installare gli aggiornamenti senza che nessuno abbia effettuato l’accesso. Gli strumenti condividono soltanto lo scopo.

Su Ubuntu e Debian il pacchetto è unattended-upgrades, configurato in /etc/apt/apt.conf.d/50unattended-upgrades, dove si specificano le origini dalle quali è autorizzato a scaricare i pacchetti. Configurare unattended-upgrades su Ubuntu illustra questo file di configurazione e la scelta relativa al riavvio.

Su Rocky Linux, AlmaLinux e Fedora il pacchetto è dnf-automatic e il comportamento dipende dal timer systemd che si abilita.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer scarica e applica gli aggiornamenti. dnf-automatic-download.timer li scarica e si arresta, lasciando all’utente l’installazione. dnf-automatic-notifyonly.timer genera soltanto un report. Ciascuna di queste unità sovrascrive l’impostazione apply_updates in /etc/dnf/automatic.conf, quindi il timer scelto è più importante di quanto indicato nel file di configurazione. L’installazione di un aggiornamento non riavvia ciò che sta ancora eseguendo il vecchio codice. Prima di considerare il sistema aggiornato, conviene quindi verificare quali aggiornamenti richiedono un riavvio e quali soltanto il riavvio di un servizio.

Per limitarlo agli aggiornamenti di sicurezza, imposta upgrade_type = security in /etc/dnf/automatic.conf. Questo filtro dipende dalla pubblicazione degli errata di sicurezza nei repository. Verifica prima con dnf updateinfo list security. Un risultato vuoto su un sistema con aggiornamenti in sospeso indica che i metadati non sono disponibili. In tal caso security non installerebbe nulla.

Su Fedora, dnf 5 ha rinominato l’unità. Si chiama dnf5-automatic.timer e legge lo stesso /etc/dnf/automatic.conf.

Il comando yum è ancora effettivamente disponibile?

Sì, ma da solo non esegue alcuna operazione. Su Rocky Linux, AlmaLinux e CentOS Stream, /usr/bin/yum è un collegamento simbolico che punta a dnf. Verifica il tuo sistema:

ls -l /usr/bin/yum
dnf --version

La sintassi precedente di yum continua a comparire nei tutorial perché la maggior parte dei comandi viene ancora inoltrata direttamente a dnf. yum install, yum remove e yum update funzionano tutti. È però opportuno abbandonare un'abitudine: yum-config-manager esiste ancora come binario autonomo nei sistemi con dnf 4, ma dnf config-manager è la sintassi usata dalla documentazione attuale e continua a funzionare quando il sistema passa a dnf 5.

dnf 4 e dnf 5: verifica prima di copiare un comando

dnf 5 è una riscrittura completa e ha modificato la sintassi di diversi comandi. Fedora 41 e versioni successive lo distribuiscono come dnf. Le distribuzioni enterprise derivate sono passate più lentamente a questa versione, quindi non dedurre la sintassi dal nome della distribuzione. Esegui dnf --version sul tuo server e leggi la prima riga: è quel numero a determinare quale sintassi devi usare qui sotto.

L'esempio più chiaro riguarda Docker, che pubblica un comando diverso per configurare il repository in ciascun caso. Su RHEL e sulle distribuzioni derivate, con dnf 4:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Su Fedora, con dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Stesso fornitore, stesso obiettivo, sintassi diversa. dnf 5 ha trasformato config-manager in uno strumento basato su sottocomandi. Per questo il vecchio flag --add-repo non è accettato e viene restituito un errore di utilizzo invece della configurazione del repository. L'altro caso che incontrerai riguarda l'abilitazione di un repository: dnf config-manager --set-enabled crb in dnf 4 diventa dnf config-manager setopt crb.enabled=1 in dnf 5.

La scelta che conta davvero

Scegliere una distribuzione server basandosi solo sul gestore dei pacchetti significa usare il criterio sbagliato. dnf e apt svolgono lo stesso lavoro e si impara la relativa terminologia in un pomeriggio. A determinare il resto dell'anno è il modello di rilascio alla base del repository. Fedora si aggiorna rapidamente e una determinata release smette di ricevere aggiornamenti circa tredici mesi dopo la pubblicazione. Questo va bene per una workstation, ma è problematico per un server che non si vuole ricostruire. Rocky Linux e AlmaLinux seguono RHEL, quindi offrono un periodo di supporto di dieci anni e versioni dei pacchetti che rimangono deliberatamente stabili. Ubuntu offre entrambi i modelli e la differenza tra le release Ubuntu LTS e quelle interim su un server corrisponde alla stessa scelta nell'ecosistema apt.

Ad agosto 2026, tutte queste distribuzioni sono immagini VPS comuni. Scegli il periodo di supporto che ti serve, quindi impara i dieci comandi precedenti.

FAQ

Qual è l'equivalente di apt update in dnf?

Non devi eseguire alcun comando. Prima di ogni transazione, dnf controlla da quanto tempo sono presenti i metadati nella cache e scarica una copia aggiornata quando sono scaduti. Di conseguenza, dnf install eseguito su un server che non tocchi da un mese usa comunque pacchetti aggiornati. Esiste sudo dnf makecache, che forza effettivamente il download, ma il suo scopo principale è spostare l'attesa a un momento scelto da te invece di introdurla durante la prossima installazione. Il comando che risponde alla domanda "che cosa mi sta aspettando" è dnf check-update, che corrisponde a apt list --upgradable ed esce con stato 100 quando sono disponibili aggiornamenti.

Esiste un equivalente di PPA su Rocky Linux o Fedora?

No. Gli archivi personali dei pacchetti sono un servizio di Launchpad, e Launchpad fa parte dell'infrastruttura Ubuntu. Pertanto add-apt-repository non ha un equivalente da tradurre. L'equivalente nel mondo RPM è un file .repo in /etc/yum.repos.d/, che contiene un nome, un baseurl e un gpgkey. I vendor pubblicano questo file per te; sudo dnf config-manager --add-repo <url> con dnf 4, oppure sudo dnf config-manager addrepo --from-repofile <url> con dnf 5, lo scarica e lo colloca nella posizione corretta. Per il software aggiuntivo di uso generale, la risposta è solitamente EPEL, che abiliti con sudo dnf config-manager --set-enabled crb seguito da sudo dnf install epel-release.

Posso annullare un aggiornamento dnf che ha causato problemi al server?

Sì, entro certi limiti. Esegui sudo dnf history per trovare il numero della transazione, sudo dnf history info <id> per vedere esattamente che cosa ha modificato, quindi sudo dnf history undo <id>. L'annullamento non riesce se la versione precedente del pacchetto non è più presente in alcun repository abilitato, perché dnf non ha nulla da reinstallare. Inoltre, annulla soltanto le modifiche ai pacchetti. Un file di configurazione riscritto dall'aggiornamento o un database migrato da un servizio al primo avvio rimane invariato. apt non dispone di alcun comando equivalente; conserva soltanto il record in /var/log/apt/history.log.

yum funziona ancora su Rocky Linux e AlmaLinux?

Sì, perché /usr/bin/yum è un collegamento simbolico a dnf. Verificalo sul tuo sistema con ls -l /usr/bin/yum. L'esecuzione di yum install httpd avvia dnf, quindi i tutorial meno recenti funzionano ancora nella maggior parte dei casi. Per i nuovi script e la nuova documentazione usa dnf, perché il nome yum esiste soltanto per compatibilità. Preferisci inoltre dnf config-manager al vecchio binario yum-config-manager.

Perché dnf remove vuole eliminare così tanti pacchetti?

Perché dnf rimuove, nella stessa transazione, le dipendenze che non servono a nient'altro, mentre apt remove le lascia installate finché non esegui separatamente apt autoremove. Per questo una rimozione che su Ubuntu sembra limitata può mostrare un elenco lungo su Rocky Linux. In genere l'elenco è corretto, ma leggilo prima di confermare. Se contiene un pacchetto che vuoi conservare, installalo prima in modo esplicito. Così dnf lo registra come pacchetto richiesto direttamente.