Da apt a dnf: comandi equivalenti su Rocky e Fedora

La risposta breve

Passare da apt a dnf è soprattutto una modifica della 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.

Ogni comando riportato di seguito è pensato per essere eseguito sul proprio server. Leggere il riepilogo della transazione visualizzato da dnf prima di rispondere a y, soprattutto quando si rimuovono pacchetti.

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 opzione. Se l'elenco delle immagini del provider offre Rocky Linux o AlmaLinux, userai dnf. Se offre Ubuntu, userai apt.

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

Qualunque sia la famiglia scelta, il primo accesso richiede le stesse operazioni. I primi dieci minuti su un nuovo VPS si applicano a entrambe. Cambia solo 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 presenta una differenza di comportamento che può causare problemi. dnf remove rimuove anche le dipendenze che non servono più ad altri pacchetti, mentre apt remove le lascia installate per un successivo apt autoremove. Per questo, rimuovere una piccola utility su Rocky Linux può proporre di rimuovere anche una dozzina di librerie. Leggere l’elenco prima di confermare.

Aggiornare i metadati, verificare gli aggiornamenti disponibili ed eseguire l’upgrade.

# 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 dal lato apt, perché apt usa i metadati presenti sul disco e può installare una versione che ha lasciato l’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 subito il download, invece di eseguirlo durante la prossima installazione.

apt divide 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 variante autorizzata a rimuoverlo. dnf non ha questa limitazione. Per questo dnf upgrade è l’equivalente di apt full-upgrade, non di apt upgrade. dnf update è un alias precedente dello stesso comando e continua a funzionare.

Se si usano questi comandi negli script, è importante un dettaglio: 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 ogni blocco risponde a una domanda diversa rispetto alle righe 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 installerei per ottenere questo file». apt-file è un pacchetto separato su Ubuntu e richiede sudo apt-file update prima del primo avvio. dnf provides non richiede componenti aggiuntivi, anche se il primo avvio 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. Dal lato apt, il comando corrispondente è 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. Di conseguenza, su un sistema appena installato la prima di queste righe termina con No such command: versionlock. Installarlo prima con sudo dnf install python3-dnf-plugin-versionlock. apt non richiede componenti aggiuntivi per apt-mark hold, perché il blocco della versione è uno stato di dpkg, non un plugin.

Dove si interrompe la corrispondenza: aggiungere un repository

Questa è la parte che spinge gli amministratori Ubuntu a cercare un comando che non esiste. 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 semplice file di testo 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 al momento dell'esecuzione il numero della release principale e l'architettura della CPU, quindi lo stesso file funziona con la versione 9 e la versione 10, nonché su x86_64 e aarch64.

La maggior parte dei vendor pubblica quel file e indica di scaricarlo. Le istruzioni ufficiali di Docker per RHEL e i relativi rebuild consistono in 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 integrata di dnf. Se la si omette, la seconda riga restituisce l'errore No such command: config-manager. È comunque possibile 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'equivalente consiste nello scrivere 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 sono mantenute separatamente in /etc/apt/keyrings/. dnf conserva tutto in /etc/yum.repos.d/ e la chiave è un URL all'interno del file .repo, quindi 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 riscontrato l'errore delle sorgenti duplicate deb822 su Ubuntu, hai già incontrato la parte del problema relativa ad apt.

EPEL è l’archivio che la maggior parte delle guide presume già abilitato

Extra Packages for Enterprise Linux (EPEL) è un progetto Fedora che compila pacchetti Fedora per RHEL e per le relative distribuzioni ricostruite. È la soluzione più simile a una PPA universale disponibile in questo ecosistema e moltissime esercitazioni presumono che sia già abilitata. Se dnf install restituisce No match for argument per un pacchetto disponibile sul sito ufficiale del progetto, EPEL è il primo elemento 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 incluso nella distribuzione ma non abilitato per impostazione predefinita. La maggior parte dei pacchetti EPEL dipende da componenti presenti al suo interno, quindi l’abilitazione di EPEL senza CRB non produce errori immediati. L’errore si verifica in seguito, durante l’installazione, con dipendenze irrisolte per un pacchetto mai utilizzato. Abilitare prima CRB elimina questa classe di errori.

Su RHEL, CRB viene fornito tramite la sottoscrizione e non tramite config-manager; per questo passaggio, seguire le istruzioni ufficiali di Red Hat per EPEL. Fedora non richiede nulla di tutto questo, perché il repository principale contiene già i pacchetti che EPEL trasferisce dalle versioni più recenti. La policy di EPEL prevede di non sostituire mai un pacchetto distribuito da RHEL, quindi l’aggiunta del repository non modifica nulla di ciò che è già installato sul server.

dnf history undo: la funzione che apt non offre

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

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

dnf history visualizza un elenco numerato delle transazioni, con la riga di comando che ha avviato ciascuna di esse. undo costruisce la transazione opposta: rimuove i pacchetti installati da quella transazione e ripristina la versione precedente dei pacchetti aggiornati. È la funzione che gli utenti di apt rimpiangono di più dopo il passaggio a dnf.

La funzione ha limiti concreti, che è importante conoscere prima di farvi affidamento. undo può reinstallare una versione del pacchetto solo se questa è ancora disponibile in un repository abilitato. Se la vecchia build è 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 durante l’aggiornamento resta riscritto e lo schema di un database migrato da un servizio al primo avvio resta migrato. dnf ripristina i file. Non ripristina i dati.

apt non dispone di 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 per impedire che l’aggiornamento successivo annulli la correzione.

I gruppi di pacchetti non hanno un equivalente in apt

dnf consente di installare un insieme nominativo di pacchetti con un solo comando.

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, la forma a due parole dnf group install è l'unica compatibile con entrambe le versioni. Usala e non pensarci più.

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

unattended-upgrades e dnf-automatic

Entrambe le famiglie consentono di installare gli aggiornamenti senza che sia necessario un accesso interattivo. Gli strumenti non condividono componenti, ma hanno lo stesso scopo.

Su Ubuntu e Debian il pacchetto è unattended-upgrades ed è configurato in /etc/apt/apt.conf.d/50unattended-upgrades, dove si specificano le origini da cui è autorizzato a scaricare i pacchetti. Configurazione degli aggiornamenti automatici su Ubuntu descrive questo file di configurazione e la gestione del riavvio necessaria in questo scenario.

Su Rocky Linux, AlmaLinux e Fedora il pacchetto è dnf-automatic. Il timer systemd da abilitare determina il comportamento.

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 a te l'installazione. dnf-automatic-notifyonly.timer si limita a generare un report. Ognuna di queste unità sovrascrive l'impostazione apply_updates in /etc/dnf/automatic.conf. Di conseguenza, il timer scelto è più importante di quanto indicato nel file di configurazione.

Per limitare l'operazione agli aggiornamenti di sicurezza, imposta upgrade_type = security in /etc/dnf/automatic.conf. Questo filtro dipende dalla pubblicazione degli avvisi di sicurezza da parte dei repository. Verificalo prima con dnf updateinfo list security. Un risultato vuoto su un sistema che ha aggiornamenti in sospeso indica che i metadati non sono disponibili. In tal caso security non installerebbe alcun aggiornamento.

Su Fedora, dnf 5 ha rinominato l'unità. Il nuovo nome è dnf5-automatic.timer e legge lo stesso file /etc/dnf/automatic.conf.

Il comando yum esiste ancora?

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 collegamento presente sul sistema:

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

Nei tutorial compare ancora la sintassi di yum perché la maggior parte dei comandi continua a funzionare senza modifiche. yum install, yum remove e yum update funzionano tutti. Conviene però abbandonare un'abitudine: yum-config-manager esiste ancora come binario autonomo nei sistemi con dnf 4, ma dnf config-manager è la sintassi usata nella 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 includono come dnf. Le distribuzioni enterprise derivate sono passate più lentamente a questa versione, quindi non dedurre la versione dal nome della distribuzione. Esegui dnf --version sul tuo server e leggi la prima riga: è quel numero a determinare la sintassi da usare.

L'esempio più chiaro riguarda Docker, che pubblica un comando diverso per configurare il repository in ciascuna versione. Su RHEL e sulle relative 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

Lo stesso fornitore, la stessa operazione, parole diverse. dnf 5 ha trasformato config-manager in uno strumento basato su sottocomandi, quindi il vecchio flag --add-repo non viene accettato e viene restituito un errore di utilizzo invece di configurare un 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 in base al solo gestore dei pacchetti significa considerare il criterio sbagliato. dnf e apt svolgono lo stesso lavoro e la relativa terminologia si apprende in un pomeriggio. A determinare il tuo anno operativo è il modello di rilascio alla base del repository. Fedora procede rapidamente e una determinata release smette di ricevere aggiornamenti dopo circa tredici mesi dalla pubblicazione. Questo va bene per una workstation, ma è problematico per un server che non vuoi ricostruire. Rocky Linux e AlmaLinux seguono RHEL, quindi offrono un periodo di supporto di dieci anni e versioni dei pacchetti che rimangono intenzionalmente stabili. Ubuntu offre entrambe le modalità e la differenza tra le release Ubuntu LTS e interim su un server corrisponde alla stessa scelta nell'ambito di apt.

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

FAQ

Qual è l'equivalente di apt update in dnf?

Non è necessario 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. Per questo, dnf install su un server che non si utilizza da un mese vede comunque i pacchetti correnti. sudo dnf makecache esiste e forza effettivamente il download, ma serve soprattutto a spostare l'attesa in un momento scelto dall'utente, invece di introdurla durante la successiva installazione. Il comando che risponde alla domanda «che cosa mi aspetta?» è dnf check-update, che corrisponde a apt list --upgradable ed esce con lo stato 100 quando sono disponibili aggiornamenti.

Esiste un equivalente dei PPA su Rocky Linux o Fedora?

No. Gli archivi personali dei pacchetti sono un servizio di Launchpad, che fa parte dell'infrastruttura Ubuntu. Pertanto, add-apt-repository non ha un equivalente diretto. L'equivalente nel mondo RPM è un file .repo nella directory /etc/yum.repos.d/, che contiene un nome, un baseurl e un gpgkey. I vendor pubblicano questo file. sudo dnf config-manager --add-repo <url> con dnf 4, oppure sudo dnf config-manager addrepo --from-repofile <url> con dnf 5, lo scarica nella posizione corretta. Per il software aggiuntivo di uso generale, la soluzione consueta è EPEL, che si abilita 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 determinati limiti. Eseguire sudo dnf history per trovare il numero della transazione, sudo dnf history info <id> per vedere esattamente quali modifiche ha apportato, quindi sudo dnf history undo <id>. L'annullamento non riesce se la versione precedente del pacchetto non è più presente in nessun repository abilitato, perché dnf non ha alcun pacchetto da reinstallare. Inoltre, annulla solo le modifiche apportate ai pacchetti. Un file di configurazione riscritto dall'aggiornamento o un database migrato da un servizio al primo avvio rimane nello stato attuale. 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. Verificarlo sul proprio sistema con ls -l /usr/bin/yum. L'esecuzione di yum install httpd avvia dnf, quindi la maggior parte dei tutorial meno recenti continua a funzionare. Per i nuovi script e la nuova documentazione, usare dnf, perché il nome yum è mantenuto solo per compatibilità. Preferire inoltre dnf config-manager al precedente binario yum-config-manager.

Perché dnf remove vuole eliminare così tanti pacchetti?

Perché dnf rimuove, nella stessa transazione, le dipendenze che non servono ad altri pacchetti, mentre apt remove le lascia installate finché non si esegue separatamente apt autoremove. Di conseguenza, una rimozione che su Ubuntu sembra limitata può mostrare un elenco lungo su Rocky Linux. L'elenco è generalmente corretto, ma va letto prima della conferma. Se contiene un pacchetto che si desidera conservare, installarlo esplicitamente prima della rimozione, in modo che dnf lo registri come richiesto direttamente dall'utente.