Come installare WineHQ su AlmaLinux 8 e Rocky Linux Desktop

WineHQ non è un pacchetto da installare “e basta”: su AlmaLinux 8 e Rocky Linux Desktop conviene trattarlo come un cambio controllato, perché la riuscita dipende da tre cose molto banali ma decisive: architettura a 64 bit, repository esterni configurati bene e librerie mancanti risolte senza forzature. Se salti i controlli iniziali, il classico risultato è un install che sembra riuscito ma poi fallisce all’avvio di applicazioni Windows, oppure un conflitto tra pacchetti del sistema e quelli del repository WineHQ.

La strada pulita è: verificare il sistema, abilitare i repository giusti, installare il ramo WineHQ adatto al caso d’uso e poi testare con un prefisso separato. Su un server AlmaLinux 8 l’obiettivo tipico è compatibilità applicativa o esecuzione di utility specifiche; su Rocky Linux Desktop spesso l’esigenza è lanciare software legacy in ambiente grafico. In entrambi i casi il principio non cambia: prima osservi, poi modifichi, poi validi.

Requisiti pratici prima di partire

WineHQ supporta solo sistemi a 64 bit. Se la macchina è a 32 bit, la chiusura del gap non è una “configurazione alternativa”: serve una reinstallazione su architettura compatibile. Verifica anche che la macchina sia aggiornata e che i repository di base funzionino, perché un sistema con metadata rotti o mirror non raggiungibili crea errori fuorvianti durante l’installazione.

Controlla subito questi punti:

uname -m

Atteso: x86_64. Se leggi qualcosa di diverso, fermati qui.

cat /etc/redhat-release

Ti serve per distinguere AlmaLinux 8, Rocky Linux 8 e varianti desktop. La procedura è praticamente identica, ma la verifica della GUI cambia il modo in cui testi il risultato.

sudo dnf repolist

Se qui trovi errori di metadata o repo non raggiungibili, risolvili prima. Non ha senso inseguire errori di Wine se il problema è già a monte.

Repo necessari su AlmaLinux 8 e Rocky Linux 8

Su queste distribuzioni il passaggio più importante è preparare i repository EPEL e il repo ufficiale WineHQ. In molti casi serve anche il supporto a pacchetti a 32 bit, ma non va abilitato “alla cieca” su ogni sistema: lo fai solo se il software Windows che devi eseguire dipende da librerie i386.

In pratica, la sequenza base è questa:

sudo dnf update -y

Questo allinea il sistema prima del cambio. Atteso: nessun errore di dipendenza o repo.

sudo dnf install -y epel-release

Su AlmaLinux 8 e Rocky 8 EPEL è spesso il pezzo che sblocca dipendenze utili. Se il pacchetto non si installa, controlla con dnf repolist e connettività DNS.

Per il repo WineHQ, il metodo più lineare è scaricare il file di configurazione del repository ufficiale. La URL può cambiare in base alla versione, quindi il controllo migliore è seguire la pagina del progetto e prendere il pacchetto repo corretto per EL 8. Se vuoi restare operativamente rigoroso, verifica sempre il file installato in /etc/yum.repos.d/ prima di procedere.

ls -l /etc/yum.repos.d/ | grep -i wine

Se il file non c’è, non forzare installazioni da sorgenti non verificate: scarica il repository ufficiale e controlla che il nome del file e il baseurl corrispondano alla release supportata.

Installazione di WineHQ: ramo stabile o development

Il ramo da scegliere dipende dal rischio accettabile. Per uso desktop o applicazioni note, il ramo stabile è la scelta sensata. Il ramo development ha senso se devi validare un bugfix o una compatibilità più recente, ma introduce più variabilità. In produzione o su workstation di lavoro, partire dal ramo stabile evita sorprese inutili.

Una volta abilitato il repo WineHQ, l’installazione tipica è questa:

sudo dnf install -y winehq-stable

Se il pacchetto non viene trovato, il problema è quasi sempre nel repository o nella release del sistema. Se invece DNF propone conflitti, spesso il sistema ha già pacchetti Wine di altri repository. In quel caso non mescolare sorgenti diverse senza criterio: rimuovi il pacchetto in conflitto o disabilita temporaneamente il repo che lo fornisce.

Per verificare cosa è stato installato:

rpm -qa | grep -i '^wine'

Atteso: una serie di pacchetti WineHQ coerenti tra loro, senza residui di versioni miste. Se vedi componenti di più repository, fermati e normalizza prima di testare.

Supporto 32 bit: quando serve davvero

Molte applicazioni Windows vecchie dipendono da librerie 32 bit. Su un sistema 64 bit questo si traduce nell’abilitazione di architettura i686 per alcuni pacchetti. Non è un obbligo universale: se installi un’app moderna a 64 bit, puoi anche non toccare nulla oltre a WineHQ.

Se ti servono componenti 32 bit, la verifica minima è questa:

sudo dnf install -y glibc.i686 libstdc++.i686

Se questi pacchetti mancano o non sono risolvibili, il problema può essere il set di repository abilitati. Non aggiungere librerie a caso: identifica prima l’errore reale dell’applicazione.

Un controllo utile, dopo l’installazione, è vedere se Wine riesce a creare il prefisso utente:

wineboot -u

Atteso: inizializzazione senza errori fatali. Il primo avvio può richiedere più tempo perché crea la struttura in ~/.wine.

Primo avvio e creazione del prefisso

Il prefisso Wine è il contenitore dove finiscono registri, drive virtuali e configurazioni dell’utente. È il punto in cui molti si incastrano perché lanciano subito un installer complesso senza aver verificato che il prefisso base funzioni. Prima fai un test semplice, poi passi al software reale.

Comando base:

winecfg

Se compare l’interfaccia grafica, il layer grafico e le librerie essenziali sono a posto. Se non hai sessione desktop, su Rocky Linux Desktop il test va eseguito dentro l’ambiente grafico dell’utente corretto, non via SSH senza forwarding, altrimenti il risultato è ambiguo.

Se vuoi isolare il test, usa un prefisso dedicato:

export WINEPREFIX=$HOME/.wine-test
wineboot -u

Questo riduce il blast radius: se il test sporca configurazioni o librerie, non tocchi il prefisso principale dell’utente. Il rollback in questo caso è banale: rimuovi la directory del prefisso di test.

Rocky Linux Desktop: integrazione con la GUI

Su Rocky Linux Desktop il tema non è solo “installare Wine”, ma farlo convivere con il desktop environment. L’associazione dei file .exe, i menu, le icone e il rendering dipendono da pacchetti desktop già presenti. Se l’installazione base va bene ma non hai integrazione grafica, il problema non è WineHQ in sé: è il livello desktop.

Un controllo utile è installare gli strumenti grafici essenziali insieme a Wine:

sudo dnf install -y winehq-stable wine-mono wine-gecko

La disponibilità esatta di wine-mono e wine-gecko dipende dal repo e dal ramo scelto. Se DNF segnala pacchetti assenti, non assumere che siano obbligatori: verifica il nome corretto con dnf search wine.

Per aprire un eseguibile Windows dalla GUI, spesso basta doppio clic dopo aver associato il file manager. Se l’associazione non compare, un test manuale dal terminale chiarisce subito se il problema è Wine o l’integrazione desktop:

wine /percorso/al/file.exe

Atteso: avvio dell’app o, almeno, un errore leggibile che dica quale componente manca. Un crash silenzioso o una finestra che non appare indica quasi sempre un problema di display, dipendenze grafiche o prefisso corrotto.

Gestione errori tipici senza perdere tempo

Gli errori più comuni non richiedono una reinstallazione completa. Serve capire il layer che sta fallendo. Se dnf non risolve il pacchetto, è un problema di repository. Se Wine si installa ma non avvia nulla, il problema è nel prefisso o nelle dipendenze runtime. Se l’app parte ma mostra schermate vuote o artefatti, il colpevole è spesso il rendering grafico o la compatibilità con librerie specifiche.

Tre controlli rapidi che fanno risparmiare tempo:

Se un’app specifica richiede DLL native, la soluzione corretta non è copiare file a mano dentro system32. Usa winetricks quando serve e solo dopo aver identificato la dipendenza. È più pulito, più ripetibile e meno fragile di una modifica artigianale del prefisso.

Uso di winetricks senza trasformare il prefisso in una discarica

winetricks è utile, ma va trattato come strumento di provisioning mirato, non come soluzione generica. Prima di installare componenti aggiuntivi, annota cosa stai facendo e su quale prefisso. Se possibile, crea un prefisso per ogni applicazione critica: riduce il rischio di conflitti tra runtime diversi.

Installazione di base, se disponibile nei repository:

sudo dnf install -y winetricks

Se il pacchetto non è presente, controlla EPEL e i repo attivi. Una volta installato, l’uso corretto è applicare solo il componente necessario. Per esempio:

export WINEPREFIX=$HOME/.wine-app
winetricks corefonts

Qui il rischio è limitato perché agisci su un prefisso dedicato. Se qualcosa va storto, il rollback più semplice è cancellare quel prefisso e ricrearlo. Questo è molto più pulito che cercare di “disinstallare” a mano singole DLL o font.

Verifica finale: non basta che il pacchetto sia presente

Un’installazione riuscita si misura con un test funzionale, non con rpm -q. Devi vedere almeno tre cose: Wine risponde, il prefisso si inizializza e un file .exe di prova si avvia oppure produce un errore coerente e diagnosticabile. Se queste tre condizioni sono vere, la base è sana.

Un test minimale e ripetibile può essere questo:

wine --version
wineboot -u
wine notepad

Atteso: versione stampata, inizializzazione senza errori fatali e apertura di Notepad o dell’applicazione grafica associata. Se Notepad non parte ma il resto sì, il problema è più spesso nel desktop integration layer o in librerie mancanti, non nell’installazione base.

Se stai lavorando su una workstation Rocky Linux Desktop, il controllo finale va fatto dall’utente reale che userà l’applicazione, perché il prefisso e la cache grafica sono per-utente. Se invece stai preparando AlmaLinux 8 per un servizio o per supporto remoto, documenta il prefisso, i pacchetti aggiunti e la motivazione. Così il mantenimento futuro non diventa archeologia.

Rollback pulito e manutenzione minima

Il rollback di un’installazione WineHQ è semplice solo se hai evitato di mischiare repository e se hai usato prefissi separati. Per rimuovere il software principale, il comando base è:

sudo dnf remove -y winehq-stable wine wine-core

Prima di eseguirlo, verifica con rpm -qa | grep -i '^wine' quali pacchetti sono presenti, perché i nomi possono variare in base al ramo installato. Dopo la rimozione, cancella solo i prefissi di test che hai creato tu:

rm -rf ~/.wine-test

Questo è un esempio di rollback a blast radius ridotto: non tocchi il prefisso principale se non sei sicuro di volerlo azzerare. Se il sistema è condiviso, documenta sempre quale utente possiede il prefisso e quali applicazioni dipendono da esso.

Assunzione: il sistema è un host x86_64 con repository DNF funzionanti; eventuali pacchetti mancanti o nomi diversi vanno verificati con i comandi indicati prima di applicare modifiche ulteriori.