EPEL e CRB: pacchetti mancanti su Rocky e AlmaLinux

Perché dnf non trova il pacchetto richiesto

EPEL e CRB sono i due repository che un server Rocky Linux o AlmaLinux appena installato non include automaticamente. Per questo, su un sistema nuovo, dnf install htop restituisce No match for argument: htop e poi Error: Unable to find a match: htop. Non c'è un problema e nessun mirror è inattivo. La distribuzione di base include volutamente un numero limitato di pacchetti. CRB è presente, ma disabilitato. EPEL è invece un repository della community separato, che devi aggiungere.

Su Ubuntu lo stesso pacchetto si trova in universe e universe è abilitato in quasi tutte le immagini cloud. Per questo la domanda non si pone. La famiglia Red Hat organizza i pacchetti in modo diverso e offre meno pacchetti per impostazione predefinita. La correzione richiede tre comandi. Il resto di questa guida tratta l'aspetto che spesso non viene spiegato nella prima settimana: cosa offrono questi repository, cosa non offrono e come impedire che un repository di terze parti prenda gradualmente il controllo del sistema di base.

Come sono stati verificati questi comandi. I nostri container di test eseguono solo Ubuntu, quindi i comandi dnf riportati di seguito non sono stati eseguiti sulle nostre macchine di test. Sono conformi alla documentazione di Rocky Linux e AlmaLinux. Ogni passaggio indica l'output previsto. Verificalo quindi sul tuo server, invece di incollare tutto il blocco in una volta sola.

Cosa sono BaseOS, AppStream e CRB?

BaseOS è il sistema operativo vero e proprio: kernel, glibc, systemd e componenti di base dello userland. Le versioni cambiano raramente durante il ciclo di vita della release principale. La maggior parte delle correzioni, incluse quelle di sicurezza, viene retroportata nella versione già installata, anche se una release minore può occasionalmente aggiornare un componente di base a una versione upstream più recente (AlmaLinux 9.2, ad esempio, ha aggiornato i pacchetti dello spazio utente di SELinux alla versione 3.5). Un numero di versione che in BaseOS sembra risalire a diversi anni fa non indica un pacchetto privo di aggiornamenti. Indica una versione precedente che ha ricevuto le correzioni necessarie. Questo è il principio alla base di una distribuzione enterprise.

AppStream contiene i componenti eseguiti sopra il sistema: server web, database, runtime dei linguaggi, editor e agenti di monitoraggio. Nella versione 8, gran parte di AppStream veniva distribuita come moduli con stream alternativi, quindi dnf module list era importante e si sceglieva, ad esempio, uno stream di PHP. La versione 9 distribuisce la versione predefinita di ogni applicazione come semplice pacchetto, quindi su Rocky 9 e Alma 9 un semplice dnf install installa quella versione senza dover prima abilitare un modulo. Le versioni alternative continuano ad arrivare come stream di moduli: RHEL 9 documenta PHP 8.0 come normale pacchetto php e PHP 8.1 e 8.2 come stream php:8.1 e php:8.2; inoltre, AlmaLinux 9.8 ha aggiunto nuovi stream come MariaDB 11.8, PostgreSQL 18 e Ruby 4.0. Se serve una versione diversa da quella predefinita, dnf module list rimane importante nella versione 9.

Extras è abilitato per impostazione predefinita ed è molto ridotto. Contiene soprattutto pacchetti di release per altri repository, ed è da qui che proviene lo stesso epel-release. Per questo non è mai necessario affidarsi a un URL casuale per installare EPEL su Rocky o Alma.

CRB è il repository CodeReady Builder, chiamato PowerTools nella versione 8. Contiene la parte della distribuzione necessaria per la compilazione: header di sviluppo, librerie statiche e strumenti per test e documentazione richiesti dai pacchetti durante la compilazione. È già presente sul mirror, ma è disabilitato per impostazione predefinita. Nel prodotto di Red Hat, lo stesso contenuto si chiama CodeReady Linux Builder, è incluso nell'abbonamento e Red Hat specifica che non è coperto dal supporto. Rocky e Alma ereditano sia il contenuto sia la disabilitazione predefinita.

Per chi arriva da Debian o Ubuntu: main combina i pacchetti runtime e gli header -dev in un unico archivio, quindi non esiste un CRB da abilitare. L'equivalente più vicino a EPEL è universe, gestito dalla comunità e privo di qualsiasi impegno di supporto da parte del fornitore.

Che cos’è EPEL e chi lo gestisce

EPEL significa Extra Packages for Enterprise Linux. È un progetto Fedora: include pacchetti disponibili in Fedora, ricompilati per la release enterprise corrente e gestiti dall’EPEL Special Interest Group, composto principalmente da volontari della community Fedora. Red Hat ospita l’infrastruttura di build e i mirror, e alcuni ingegneri Red Hat gestiscono pacchetti al suo interno. Il rapporto termina qui. EPEL non è un prodotto Red Hat. Per un pacchetto EPEL, su RHEL o su una sua rebuild, non esistono né un contratto di supporto né uno SLA (service level agreement).

Una policy rende EPEL sicuro da abilitare: un pacchetto EPEL non deve mai sostituire un pacchetto della distribuzione di base. Se AppStream distribuisce nginx, EPEL non lo farà. Questa regola viene applicata dalle persone che revisionano i pacchetti EPEL, quindi è una garanzia limitata a EPEL. Non offre alcuna protezione rispetto ad altri repository aggiunti in seguito.

Anche la garanzia sulla durata è diversa da quella della distribuzione di base, e il problema si manifesta soprattutto nel terzo anno. Un pacchetto BaseOS mantiene in genere la propria versione per l’intero ciclo di vita decennale della release principale, ricevendo correzioni retroportate e solo occasionali rebase pianificati. Un maintainer EPEL si impegna invece per un periodo molto più breve: la proposta di EPEL sulla durata dei pacchetti in base alla release lo definisce come almeno una release minor di RHEL o 13 mesi, a seconda di quale periodo sia più breve. Nella pratica, la maggior parte dei pacchetti viene mantenuta molto più a lungo. Alcuni vengono ritirati quando il maintainer interrompe la manutenzione, mentre altri passano a una nuova major version durante il ciclo di vita della distribuzione, perché EPEL segue Fedora. Di conseguenza, un normale dnf upgrade può installare una nuova major version di uno strumento EPEL su una macchina che si pensava stabile; inoltre, un pacchetto da cui dipendi può smettere di ricevere aggiornamenti senza alcun annuncio che ti raggiunga. Una nuova versione non diventa operativa in un servizio già in esecuzione. Per questo needs-restarting indica quali processi utilizzano ancora il vecchio binario al termine della transazione.

Prima di abilitarlo, è importante conoscere un’ulteriore conseguenza: EPEL non viene compilato per la release minor precedente su cui potresti aver mantenuto un server. La policy EPEL di Fedora compila la release minor EPEL 10 più recente utilizzando CentOS Stream 10 e le release minor EPEL 10 precedenti utilizzando specifiche release minor di RHEL 10. EPEL 8 e 9 hanno definizioni di destinazione proprie. Se mantieni un server su una release minor precedente, usando un mirror congelato o il repository di una point release del vendor, un pacchetto EPEL può richiedere una libreria di base più recente di quella installata. dnf segnala il problema come dipendenza mancante. Può sembrare un problema del mirror, ma in realtà si tratta di una versione non allineata.

Abilitare CRB e installare EPEL su Rocky o Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled dovrebbe ora elencare baseos, appstream, extras, crb e epel. Potresti vedere anche una voce epel-cisco-openh264 di dimensioni ridotte, aggiunta da epel-release. Se crb non compare nell’elenco, il passaggio di abilitazione non è andato a buon fine. La sezione successiva spiega il motivo.

Su Rocky 8 e Alma 8 il repository si chiama ancora PowerTools, quindi il comando centrale diventa sudo dnf config-manager --set-enabled powertools. Gli identificativi dei repository distinguono tra maiuscole e minuscole. La documentazione meno recente per CentOS 8 lo indica come PowerTools con le maiuscole, ma questo valore non corrisponde. Su AlmaLinux 10 il repository CRB è abilitato per impostazione predefinita a partire dalla versione 10.0, in seguito alla modifica di settembre 2025. In questo caso è quindi sufficiente il passaggio epel-release.

epel-release proviene da extras, che è già abilitato. Non devi quindi verificare alcun URL né importare manualmente alcuna chiave. Il pacchetto scrive /etc/yum.repos.d/epel.repo e installa la chiave di firma EPEL in /etc/pki/rpm-gpg/. Verifica gpgcheck=1 in quel file e ignora le guide che indicano di aggirare un errore di firma usando --nogpgcheck. Se il controllo della firma non riesce, il pacchetto potrebbe non essere quello dichiarato oppure l’orologio di sistema potrebbe essere errato.

Su Rocky, epel-release installa anche un piccolo strumento ausiliario in /usr/bin/crb. Di conseguenza, sudo crb enable e crb status svolgono la stessa funzione senza il plugin. Prima di farvi affidamento, verifica se è presente con command -v crb, perché non è disponibile in ogni ramo di ogni rebuild.

Per verificare che EPEL sia raggiungibile, e non soltanto elencato, richiedi un pacchetto disponibile esclusivamente in quel repository:

dnf repoquery --repo=epel htop

Il comando stampa il nome, la versione e l’architettura del pacchetto. Nessun output indica che il repository è abilitato ma non restituisce risultati. Di solito si tratta di un problema del mirror o dei metadati, non di configurazione. Prova quindi sudo dnf clean all && sudo dnf makecache.

Perché dnf restituisce «no such command: config-manager»

Questo è il primo problema in cui ci si imbatte e si verifica proprio nelle immagini fornite dalla maggior parte dei provider VPS.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager è un plugin, non un sottocomando integrato di dnf. È incluso in dnf-plugins-core, che viene installato nelle installazioni complete del server, ma non nelle immagini minimali, nelle immagini cloud e nelle immagini dei container. Il suggerimento di dnf funziona perché il pacchetto dichiara questa capacità virtuale:

sudo dnf install -y 'dnf-command(config-manager)'

Racchiudetelo tra virgolette. Le parentesi fanno parte della sintassi della shell, quindi una versione senza virgolette restituisce un errore di sintassi della shell, non un errore di dnf.

Se non potete installare il plugin perché il repository necessario è quello disabilitato, modificate direttamente il file. Individuate il file che contiene la sezione, apritelo e impostate enabled=1 sotto [crb]:

grep -rl crb /etc/yum.repos.d/

È esattamente ciò che scrive config-manager, quindi la modifica manuale non comporta alcuna perdita. dnf repolist --enabled conferma il risultato.

Alcuni pacchetti EPEL non si installano finché CRB non è abilitato

Il secondo problema comune genera un errore che non cita mai CRB. Un pacchetto EPEL che dipende da una libreria disponibile solo in CRB non supera la risoluzione delle dipendenze. Il messaggio indica la libreria e il pacchetto che la richiede:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

La causa è che CRB è disabilitato, quindi dnf non può consultare l'unico repository che fornisce quella libreria. Verificate questi due elementi nell'ordine indicato:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Se il secondo comando indica un pacchetto mentre l'installazione semplice continua a non riuscire, CRB è disabilitato. Questo tipo di errore è abbastanza comune che AlmaLinux abbia abilitato CRB per impostazione predefinita nella versione 10, proprio per evitarlo. --enablerepo=crb funziona anche come flag una tantum per una singola installazione, ma lasciate CRB abilitato in modo permanente se usate EPEL, perché il successivo aggiornamento di EPEL potrebbe introdurre una nuova dipendenza da CRB senza avvisare preventivamente.

Da quale repository proviene questo pacchetto?

Dopo alcune settimane con quattro repository abilitati, la domanda utile non è più che cosa è installato, ma da dove proviene.

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info su un pacchetto installato stampa una riga From repo. dnf list installed mostra le stesse informazioni nella terza colonna, precedute da @. Di conseguenza, @epel indica che il pacchetto è stato installato da EPEL, mentre @System indica che dnf non sa da dove proviene. In genere, questo significa che qualcuno ha eseguito rpm -i su un file scaricato. La riga repoquery fornisce il conteggio per repository. È il modo più rapido per scoprire che un server ereditato contiene quaranta pacchetti provenienti da un repository che non hai mai sentito nominare. L'ultimo comando elenca esattamente i pacchetti forniti da un repository. Questo inventario è necessario prima di decidere di rimuoverlo.

L'equivalente nell'ambiente apt è apt-cache policy <package>. Conviene tenere aperte in una seconda scheda le corrispondenze tra i comandi dnf e apt per il primo mese, perché i concetti corrispondono anche quando le opzioni sono diverse.

Come impedire che un repository di terze parti sostituisca un pacchetto di base?

EPEL promette di non farlo. Nessun altro repository lo garantisce. Un repository del fornitore per un database, un agent o un runtime del linguaggio può distribuire una propria build di una libreria fornita anche da BaseOS, e dnf la installerà perché la regola predefinita di dnf è semplice: vince la versione più alta, indipendentemente dalla sua origine.

Due impostazioni svolgono la maggior parte del lavoro e si trovano entrambe nel file del repository in /etc/yum.repos.d/.

priority= stabilisce quale repository prevale quando più repository contengono un pacchetto con lo stesso nome. Vincono i numeri più bassi e il valore predefinito è 99. Assegna quindi un numero basso ai repository di base e uno alto ai repository di terze parti. dnf userà così il pacchetto di base anche quando la versione di terze parti è più recente. Le versioni moderne di dnf gestiscono autonomamente questo comportamento, quindi il pacchetto separato yum-plugin-priorities dell'epoca di CentOS 7 non fa più parte della soluzione.

includepkgs= è l'opzione di filtro più restrittiva. excludepkgs= blocca dal repository i pacchetti indicati, ma richiede di prevedere quali pacchetti potrebbe distribuire. includepkgs= inverte il comportamento: questo repository può fornire solo i nomi indicati. Se un repository del fornitore deve fornire esclusivamente il proprio agent, basta una riga.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Nella versione 8 è necessario conoscere un'altra impostazione. Un pacchetto proveniente da un repository di terze parti può essere nascosto quando un modulo AppStream fornisce lo stesso nome. module_hotfixes=1 nella sezione del repository ordina a dnf di interrompere questo filtraggio. Se un pacchetto sicuramente presente nel repository del fornitore risulta mancante o non si installa su un sistema con versione 8, questa è solitamente la causa: il filtraggio modulare lo rende invisibile alla maggior parte dei comandi dnf, invece di segnalare un conflitto. La versione 9 contiene meno moduli, ma distribuisce ancora flussi di moduli. Lo stesso filtraggio può quindi applicarsi anche lì quando un pacchetto del fornitore ha lo stesso nome di un pacchetto modulare.

Per vincolare un pacchetto a una versione specifica, installa python3-dnf-plugin-versionlock e usa sudo dnf versionlock add <package>. È l'equivalente di apt-mark hold. Nota una differenza che può confondere chi proviene da Debian: in apt vince un Pin-Priority più alto, mentre in dnf vince un priority più basso.

Perché mescolare repository adiacenti di RHEL rende un server non aggiornabile

Rocky, Alma, CentOS Stream, Oracle Linux e RHEL sono abbastanza simili da consentire l'installazione reciproca dei rispettivi pacchetti, ma abbastanza diversi da produrre un sistema che nessuno può più supportare. Il motivo per cui sono così simili, e per cui oggi Stream si trova davanti a RHEL invece che affiancato, è la storia della divisione di Red Hat Linux in Fedora e RHEL e dell'evoluzione di CentOS.

Il meccanismo dipende dai numeri di versione. CentOS Stream 9 precede RHEL 9 nello sviluppo e Red Hat descrive il codice di Stream come quello destinato a diventare la successiva release minor di RHEL. Se punti anche una sola volta un sistema Rocky 9 a un repository Stream, persino per un solo pacchetto, ti ritrovi con pacchetti le cui versioni sono più recenti di quelle attualmente distribuite da Rocky. Una release minor successiva di Rocky potrebbe raggiungere quella versione, ma nulla garantisce che distribuisca il pacchetto con una versione uguale o superiore alla tua; fino ad allora, dnf upgrade non lo toccherà. Il sistema esegue ora una combinazione che nessuno ha testato e può rimanere in questo stato per anni senza che tu te ne accorga, mentre pensi che sia aggiornato.

Il sintomo è dnf upgrade che non segnala nulla da fare, mentre sudo dnf distro-sync propone il downgrade di un lungo elenco di pacchetti. distro-sync è lo strumento di ripristino: forza la corrispondenza di ogni pacchetto installato con ciò che i repository abilitati offrono effettivamente, inclusi i downgrade. Disabilita prima il repository esterno, quindi esegui lo strumento e leggi l'elenco proposto prima di accettare. Il ripristino non riesce quando l'RPM precedente non è più disponibile sul mirror; a quel punto ricreare il server da un'immagine pulita è più rapido e sicuro che cercare di risolvere il problema con il risolutore delle dipendenze.

I residui di ELevate sono l'altra variante comune dello stesso problema. ELevate è lo strumento di migrazione di AlmaLinux basato su Leapp, usato per portare avanti un sistema CentOS 7 o per eseguire la conversione tra rebuild. Una migrazione eseguita troppo rapidamente lascia i file dei repository EL7 in /etc/yum.repos.d/ e mantiene installati i pacchetti EL7. Individuali con rpm -qa | grep el7. Ognuno di essi è un pacchetto che nessun repository abilitato potrà mai aggiornare. Una successiva esecuzione di Leapp li segnala come pacchetti non associabili, trasformandoli in un blocco dell'upgrade da rimuovere manualmente. Rimuovili quando il server è operativo e stabile, non il giorno in cui ti serve il successivo upgrade major.

Un repository del fornitore che prevale su un pacchetto AppStream è la versione meno grave dello stesso problema, e la riga includepkgs precedente è la soluzione. Gli strumenti per i container sono il caso più comune, perché containerd.io proveniente dal repository di Docker entra in conflitto con runc proveniente da AppStream; quindi uno dei due deve essere rimosso. Prendi una decisione, annota l'esclusione e segui un ordine verificato: la guida Installare Docker su Rocky Linux indica quali pacchetti della distribuzione rimuovere per primi.

La traduzione da apt a dnf per i repository

• /etc/apt/sources.list.d/*.sources diventa /etc/yum.repos.d/*.repo, dove un unico file può contenere diversi [sections], ciascuno con il proprio ID.
• add-apt-repository universe diventa dnf install epel-release, con la differenza che universe fa ancora parte dell'archivio di Ubuntu, mentre EPEL è un progetto separato.
• apt update non ha un equivalente da ricordare. dnf aggiorna i metadati secondo una propria pianificazione e dnf makecache forza l'aggiornamento immediato.
• apt-cache policy <pkg> diventa dnf info <pkg>, con dnf list --showduplicates <pkg> aggiunto per visualizzare tutte le versioni disponibili.
• apt-mark hold diventa dnf versionlock add, a partire da python3-dnf-plugin-versionlock.
• Il pinning in /etc/apt/preferences.d/ diventa priority= nella sezione del repository, con numeri che procedono in ordine inverso.
• dpkg -S /path/to/file diventa rpm -qf /path/to/file.

Gli aggiornamenti automatici si trasferiscono come concetto, non come sintassi, perché qui non esiste unattended-upgrades. Il timer, il file di configurazione e la scelta se riavviare il sistema sono descritti in dnf-automatic su Rocky e Alma.

Mantieni breve l’elenco dei repository

Abilita CRB, installa epel-release, quindi annota che cosa hai fatto e perché, nel tuo sistema di gestione della configurazione oppure in un file semplice sul server. Questa nota è più utile di quanto sembri quando il server ha tre anni e a gestirlo è un’altra persona.

Cerca prima di aggiungere. Esegui dnf search, poi dnf info e solo dopo valuta l’aggiunta di un nuovo repository. Una parte sorprendentemente ampia dei pacchetti per i quali si abilita EPEL è già disponibile in AppStream. Il monitoraggio del sistema è l’esempio più evidente: Performance Co-Pilot è disponibile nei repository di base e non richiede repository di terze parti. Ogni repository aggiuntivo introduce un altro soggetto che può fornirti un pacchetto in qualsiasi momento, anche senza preavviso, e rende più complesso il successivo aggiornamento alla release principale.

Se stai ancora scegliendo tra le due distribuzioni, questa organizzazione è identica in entrambe e epel-release si comporta nello stesso modo. Le differenze effettive sono altrove: il confronto tra Rocky Linux e AlmaLinux illustra la diversa filosofia dei rebuild, perché AlmaLinux ora punta alla compatibilità ABI (application binary interface) invece di un rebuild riga per riga.

FAQ

Come si abilita EPEL su Rocky Linux 9 o AlmaLinux 9?

Eseguire sudo dnf install -y dnf-plugins-core, quindi sudo dnf config-manager --set-enabled crb e poi sudo dnf install -y epel-release. Verificare con dnf repolist --enabled, che dovrebbe elencare baseos, appstream, extras, crb e epel. Abilitare CRB prima di installare i pacchetti EPEL, perché molti dipendono da librerie fornite soltanto da CRB. Nella versione 8 l'ID del repository è powertools anziché crb.

È sicuro abilitare EPEL su un server di produzione?

EPEL è ampiamente utilizzato e si basa su una policy secondo cui i pacchetti EPEL non sostituiscono mai i pacchetti della distribuzione di base. Abilitarlo non modifica quindi i pacchetti forniti da BaseOS o AppStream. Il limite riguarda il supporto: EPEL è un progetto Fedora gestito da volontari e non offre alcun accordo sul livello di servizio. Inoltre, la proposta sulla durata dei pacchetti EPEL chiede a un maintainer di garantire un pacchetto per un periodo che può essere di una sola release minor di RHEL o di 13 mesi. Mantenere un inventario con dnf repository-packages epel list installed e usare dnf versionlock per ogni pacchetto EPEL da cui dipende un servizio esposto ai clienti.

Perché dnf restituisce no such command: config-manager?

Perché config-manager è un plugin di dnf e non un comando integrato. Le immagini minimali o le immagini container vengono distribuite senza dnf-plugins-core. Il messaggio indica direttamente la correzione: sudo dnf install -y 'dnf-command(config-manager)', racchiuso tra virgolette affinché la shell non interpreti le parentesi. Se non è ancora possibile installare nulla, eseguire grep -rl crb /etc/yum.repos.d/, aprire il file indicato e impostare manualmente enabled=1 nella sezione [crb].

Qual è la differenza tra CRB e PowerTools?

Sono lo stesso repository con due nomi diversi. La versione 8 lo chiama PowerTools e usa l'ID powertools. La versione 9 e le successive lo chiamano CRB e usano l'ID crb. Il prodotto Red Hat corrispondente chiama questo contenuto CodeReady Linux Builder. Il repository contiene header di sviluppo, librerie statiche e strumenti per la compilazione. Su Rocky e AlmaLinux 9 è disabilitato per impostazione predefinita. AlmaLinux 10 lo abilita per impostazione predefinita a partire dalla versione 10.0. Controllare quindi dnf repolist --enabled prima di eseguire il comando di abilitazione.

Come si rimuove EPEL senza causare problemi?

Creare prima un inventario con dnf repository-packages epel list installed, perché la rimozione del solo pacchetto epel-release non rimuove i pacchetti installati da EPEL. Questi pacchetti restano sul disco, non ricevono più aggiornamenti dalla relativa origine e smettono di ricevere correzioni di sicurezza, senza alcun errore che lo segnali. Valutare ogni pacchetto singolarmente, rimuovere o sostituire quelli non più necessari e solo dopo eseguire sudo dnf remove epel-release. Se un pacchetto proveniente da EPEL non ha sostituito nulla e deve semplicemente essere rimosso, sudo dnf repository-packages epel remove elimina l'insieme in un'unica transazione. Leggere quindi con attenzione l'elenco proposto prima di confermare.