Installare GDAL su Amazon Linux 2023 in tre modi funzionanti

Su Amazon Linux 2023 GDAL non va trattato come un pacchetto “qualsiasi”: dipende dal livello di compatibilità che ti serve, da quanto vuoi restare aderente ai repository ufficiali e da quanta libertà ti serve sulle librerie geospaziali. In pratica ci sono tre approcci che funzionano davvero: installazione dai repository disponibili, uso di un repository esterno compatibile oppure compilazione da sorgente. La scelta non è cosmetica: cambia il set di feature, il livello di manutenzione e il rischio di rompere dipendenze già presenti sul sistema.

Se il tuo obiettivo è avere gdalinfo operativo il prima possibile, la prima strada è la più pulita. Se invece ti servono driver specifici, versioni più recenti di PROJ o una build con opzioni precise, allora conviene spostarsi su repo esterno o compilazione. Su Amazon Linux 2023 il punto critico non è solo installare GDAL, ma farlo senza trascinarsi un mix instabile di librerie native.

Come decidere prima di installare

Prima di toccare il sistema, chiarisci tre cose: quale comando ti serve, quale versione ti basta e se devi usare GDAL da shell, da Python o da un’applicazione server. Un’installazione “buona” per gdalinfo può non esserlo per Python bindings o per un servizio che usa anche proj, geos e driver raster/vector specifici.

Per verificare lo stato iniziale, controlla i repository attivi e se GDAL è già presente. Questo ti evita di sovrapporre pacchetti da origini diverse senza accorgertene.

sudo dnf repolist --enabled
rpm -q gdal gdal-libs python3-gdal 2>/dev/null
command -v gdalinfo || true
gdalinfo --version 2>/dev/null || true

Se rpm -q restituisce “package gdal is not installed”, hai margine per scegliere la strada migliore. Se invece trovi già pacchetti installati da sorgenti eterogenee, prima documenta la situazione con rpm -qa | grep -E '^gdal|^proj|^geos|^sqlite' e valuta un allineamento, non un’aggiunta a caso.

Metodo 1: installazione dai repository disponibili

Questa è la via da provare per prima quando ti serve una soluzione semplice e reversibile. Su Amazon Linux 2023 la disponibilità esatta può variare in base ai repository abilitati e all’immagine di base usata. Il criterio è banale: se il pacchetto è disponibile, installalo da lì e fermati. È il modo con meno attriti per mantenere coerenza con il resto della distribuzione.

Inizia con una ricerca mirata. Se il pacchetto esiste, installa sia il binario sia le librerie, e solo dopo valuta i binding per Python.

sudo dnf search gdal
sudo dnf info gdal gdal-libs python3-gdal
sudo dnf install -y gdal gdal-libs python3-gdal

Se dnf search non mostra nulla, non forzare: passare direttamente a una build manuale senza capire il perché spesso porta a conflitti con proj, libtiff o sqlite. Se invece l’installazione va a buon fine, la verifica minima è questa:

gdalinfo --version
python3 -c 'from osgeo import gdal; print(gdal.VersionInfo())'

Il risultato atteso è una versione stampata senza errori di libreria condivisa. Se gdalinfo parte ma Python fallisce con ModuleNotFoundError: No module named osgeo, hai installato il binario ma non i binding. In quel caso il fix è installare il pacchetto Python corrispondente, non reinventare il modulo a mano.

Questo metodo ha il vantaggio di essere pulito anche in rollback: basta rimuovere i pacchetti installati di recente. Prima di farlo, però, verifica l’elenco esatto per non togliere dipendenze condivise con altri servizi.

rpm -q --whatrequires gdal-libs
sudo dnf remove -y gdal gdal-libs python3-gdal

Il rischio operativo qui è basso, ma il blast radius non è zero: se un’applicazione già usa GDAL, la rimozione la rompe immediatamente. Quindi questo approccio è adatto quando stai installando su una macchina dedicata o su un nodo in cui hai confermato l’assenza di dipendenze applicative.

Metodo 2: repository esterno o pacchetti precompilati

Quando i repository standard non offrono il pacchetto, ma vuoi evitare la compilazione completa, il compromesso è un repository esterno affidabile o un set di RPM precompilati compatibili con Amazon Linux 2023. Qui la parola chiave è compatibilità: non basta che il pacchetto si installi, deve anche legarsi correttamente alle librerie del sistema e non sostituire componenti critici con versioni incompatibili.

Questo metodo ha senso se il repo esterno è mantenuto, documenta chiaramente le dipendenze e non ti costringe a fare downgrade di librerie base. La regola pratica è semplice: aggiungi il repo, verifica il pacchetto, installa, testa. Niente salti.

# esempio generico: aggiunta repository via file .repo o rpm di rilascio
sudo dnf install -y https://example.repo/path/to/repo-release.rpm
sudo dnf repolist --enabled | grep -i gdal
sudo dnf info gdal

Non esiste un unico repository “giusto” per tutti gli ambienti, quindi qui il gap va chiuso con un controllo esplicito: apri il file di configurazione del repository in /etc/yum.repos.d/ e verifica baseurl, gpgcheck e priorità. Se il pacchetto arriva da una sorgente esterna, la firma GPG non è un dettaglio.

Una volta installato, testa le dipendenze dinamiche. È il punto che distingue una installazione sana da una che esploderà al primo avvio del servizio.

sudo dnf install -y gdal
ldd /usr/bin/gdalinfo | sort
rpm -q gdal gdal-libs
strings /usr/bin/gdalinfo | grep -i proj | head

Se ldd mostra librerie “not found”, il pacchetto è formalmente installato ma non eseguibile. In quel caso non aggiungere workaround alla cieca: individua la libreria mancante e verifica se arriva dal sistema base o dal repository esterno. Il fix corretto è allineare il set di RPM, non copiare file a mano in /usr/lib64.

Questo approccio ha un blast radius medio: tocchi la fiducia nei repository e potenzialmente introduci librerie nuove. Il rollback deve essere preparato prima, cioè sapere quale repo hai aggiunto e quali pacchetti hai installato da lì.

sudo dnf history
sudo dnf remove -y gdal gdal-libs python3-gdal
sudo rm -f /etc/yum.repos.d/nome-repo.repo
sudo dnf clean all

Metodo 3: compilare GDAL da sorgente

La compilazione da sorgente è la strada più flessibile e anche quella che richiede più disciplina. Serve quando vuoi una versione specifica, driver abilitati o disabilitati con precisione, oppure quando il pacchetto disponibile non risolve il tuo caso d’uso. In ambienti di produzione, però, va trattata come un change controllato: documentazione, prerequisiti, install path separato e rollback chiaro.

Prima di partire, installa i tool di build e le dipendenze più comuni. I nomi esatti dei pacchetti possono variare leggermente, ma il principio è sempre lo stesso: compila solo se hai già verificato che il sistema possiede le librerie di sviluppo richieste.

sudo dnf groupinstall -y "Development Tools"
sudo dnf install -y wget tar make cmake gcc gcc-c++ \ python3-devel sqlite-devel proj-devel geos-devel zlib-devel libjpeg-turbo-devel \ libtiff-devel libpng-devel curl-devel expat-devel

Se qualche pacchetto “-devel” non esiste nel tuo mirror, non andare avanti a tentativi: usa dnf provides '*/nomefile.h' o dnf search nomepacchetto per chiudere il gap. La compilazione di GDAL fallisce spesso non per il codice, ma per una dipendenza di sviluppo mancante o per una versione ABI non coerente.

Scarica una release stabile, verifica l’hash se disponibile e compila in una directory separata. Evita di installare direttamente sopra il pacchetto di sistema se non hai un motivo molto preciso.

cd /usr/local/src
sudo wget https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0.tar.gz
sudo tar -xzf gdal-3.9.0.tar.gz
cd gdal-3.9.0
./configure --prefix=/opt/gdal-3.9.0 --with-proj --with-geos --with-sqlite3
make -j"$(nproc)"
sudo make install

Se preferisci CMake, puoi usare un flusso equivalente. La scelta tra configure e cmake dipende dalla release e dalle opzioni che vuoi controllare; l’importante è mantenere il prefisso separato.

cd /usr/local/src/gdal-3.9.0
cmake -S . -B build \ -DCMAKE_INSTALL_PREFIX=/opt/gdal-3.9.0 \ -DGDAL_USE_PROJ=ON \ -DGDAL_USE_GEOS=ON \ -DGDAL_USE_SQLITE3=ON
cmake --build build -j"$(nproc)"
sudo cmake --install build

Dopo l’installazione, esponi il nuovo binario senza sporcare il sistema globale. Il modo corretto è aggiornare il PATH per la sessione o per il servizio che ne ha bisogno.

export PATH=/opt/gdal-3.9.0/bin:$PATH
export LD_LIBRARY_PATH=/opt/gdal-3.9.0/lib64:/opt/gdal-3.9.0/lib:$LD_LIBRARY_PATH
gdalinfo --version

Qui il blast radius è il più alto: una build custom può entrare in conflitto con pacchetti di sistema, script di avvio e servizi che si aspettano librerie in posizioni standard. Il rollback deve essere immediato e semplice: rimuovi il prefisso custom e ripristina l’ambiente precedente, senza toccare il resto del sistema.

Python, virtualenv e integrazione applicativa

Molti installano GDAL pensando solo al binario, poi scoprono che l’applicazione usa i binding Python. Qui il punto è non mischiare ambienti: se il sistema fornisce python3-gdal, usalo nel Python di sistema; se invece lavori in virtualenv, valuta di installare il binding compatibile con quella versione di Python e con le stesse librerie native.

La verifica minima nel virtualenv è questa:

python3 -m venv /opt/venv-gis
source /opt/venv-gis/bin/activate
python -m pip install --upgrade pip
python -c 'from osgeo import gdal; print(gdal.VersionInfo())'

Se il modulo non si importa, non è sempre colpa del pip. Spesso il binding Python è stato compilato contro una versione diversa di GDAL o contro librerie native non visibili nel runtime del virtualenv. In quel caso il controllo utile è python -c 'import sys; print(sys.path)' e, soprattutto, ldd sui moduli condivisi installati dal pacchetto.

Se devi integrare GDAL in un servizio systemd, evita di affidarti a variabili d’ambiente lasciate a mano nella shell. Metti il path nel file unit o in un drop-in dedicato e documenta il motivo. Un esempio minimale:

# /etc/systemd/system/mio-servizio.service.d/gdal.conf
[Service]
Environment="PATH=/opt/gdal-3.9.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
Environment="LD_LIBRARY_PATH=/opt/gdal-3.9.0/lib64:/opt/gdal-3.9.0/lib"

Dopo ogni modifica a systemd, ricarica e testa il servizio. Non dare per scontato che il binario funzioni nella shell e nel demone allo stesso modo.

sudo systemctl daemon-reload
sudo systemctl restart mio-servizio
sudo systemctl status mio-servizio --no-pager

Verifica finale: cosa deve essere vero

Una installazione GDAL sana su Amazon Linux 2023 deve soddisfare almeno questi punti: gdalinfo risponde con una versione coerente, le librerie condivise sono risolvibili, i binding Python funzionano se ti servono e il metodo scelto è coerente con il tuo modello di manutenzione. Se uno di questi punti non torna, non considerare il lavoro chiuso.

La verifica finale più utile è combinare comando, librerie e funzionalità reale. Per esempio, apri un dataset di test o stampa le informazioni su un GeoTIFF noto:

gdalinfo /percorso/al/file.tif | head -n 20
python3 -c 'from osgeo import gdal; ds=gdal.Open("/percorso/al/file.tif"); print(ds.RasterXSize, ds.RasterYSize) if ds else print("open failed")'

Se il file si apre e le dimensioni raster sono corrette, hai validato non solo la presenza del pacchetto ma anche il percorso di esecuzione end-to-end. È il controllo che conta davvero in ambienti geospaziali, dove una libreria può essere “installata” e comunque non essere utile.

Quale dei tre metodi scegliere davvero

Se il pacchetto ufficiale c’è, scegli quello. Se non c’è ma trovi un repository esterno mantenuto bene, usalo solo dopo aver verificato firma, dipendenze e compatibilità. Se ti serve controllo completo o una versione precisa, compila da sorgente e tieni l’installazione isolata in /opt o in un prefisso equivalente.

La regola pratica è questa: più ti avvicini alla produzione, più conta la reversibilità. GDAL non è difficile da installare; è facile, invece, installarlo in modo che funzioni oggi e diventi un problema domani. Trattalo come una dipendenza di runtime, non come un tool usa-e-getta.