Su Debian 11 e 12 la scelta sensata, quando serve una distribuzione TeX prevedibile e allineata a upstream, è TeX Live Vanilla: niente pacchetti spezzettati del sistema, niente dipendenza dalla versione inclusa nei repository Debian, e soprattutto niente sorprese quando un progetto richiede una release specifica o un set di pacchetti recente. La controparte è chiara: ti gestisci tu l’installazione, gli aggiornamenti e il percorso binari.
La logica operativa è semplice: si scarica l’installer ufficiale, si monta un albero sotto /usr/local/texlive, si espone il PATH, si inizializza l’indice dei file e si verifica che pdflatex, xelatex o lualatex puntino davvero alla release voluta. Se il sistema ha già pacchetti TeX installati da apt, conviene decidere subito se convivere o sostituire, perché mescolare le due fonti crea debugging inutile.
Quando ha senso usare TeX Live Vanilla
TeX Live Vanilla è la scelta giusta quando vuoi un ambiente coerente con CTAN e con la documentazione ufficiale di TeX Live. In pratica: build riproducibili, pacchetti aggiornati, niente ritardi dovuti al freeze della distro, e controllo diretto della versione. È utile su server di build, workstation tecniche, ambienti CI e macchine dove la compatibilità con un template o con una classe LaTeX recente conta più della comodità di apt install texlive-*.
Su Debian 11 e 12 il pacchetto texlive dei repository può bastare per uso generico, ma non è la stessa cosa: la versione è quella della distribuzione, il set di pacchetti è più conservativo e l’allineamento con upstream non è immediato. Se devi compilare documenti che dipendono da pacchetti nuovi o vuoi evitare differenze tra ambienti, Vanilla riduce la variabilità.
La contropartita è amministrativa: aggiornamenti periodici manuali, spazio disco non banale e una policy chiara per il PATH. Se l’obiettivo è un desktop condiviso da utenti non tecnici, spesso la versione Debian è più pratica. Se l’obiettivo è un sistema da build, Vanilla è più pulita.
Prerequisiti e scelta dell’architettura di installazione
Prima di iniziare, serve spazio: un’installazione completa può superare facilmente diversi gigabyte. Anche una selezione ridotta cresce nel tempo con font, classi e pacchetti aggiuntivi. Verifica il filesystem di destinazione e la politica backup prima di mettere mano a /usr/local.
La scelta più lineare è installare sotto /usr/local/texlive/<anno>, mantenendo il layout standard di TeX Live. In questo modo l’aggiornamento annuale è gestibile con una nuova directory e il vecchio albero resta disponibile per rollback o confronto. Evita installazioni “creative” in path arbitrari: ti complichi solo la manutenzione.
Se sul sistema sono già presenti pacchetti TeX da Debian, controlla subito quali binari vengono risolti dal shell. È il primo punto dove si scoprono conflitti tra installazioni multiple.
which pdflatex
pdflatex --version
which tlmgr
Se which pdflatex punta a /usr/bin/pdflatex e non a /usr/local/texlive/.../bin/x86_64-linux/pdflatex, il sistema sta ancora usando i pacchetti Debian. Non è un errore in sé, ma va deciso consapevolmente.
Installazione base con l’installer ufficiale
Il flusso standard è scaricare l’installer, verificarne l’integrità se vuoi una catena più pulita, avviarlo e scegliere una installazione locale. In ambienti tecnici conviene usare il profilo testuale, perché è ripetibile e documentabile.
mkdir -p /tmp/texlive-install
cd /tmp/texlive-install
wget https://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz
Il link mirror.ctan.org ti porta a uno specchio vicino. Se vuoi chiudere il cerchio sulla sicurezza, puoi verificare checksum e firma dal sito TeX Live o dal mirror scelto; il dettaglio operativo dipende dal workflow locale, ma il principio resta quello: non installare alla cieca su una macchina di produzione.
tar -xzf install-tl-unx.tar.gz
cd install-tl-*/
sudo ./install-tlL’interfaccia testuale permette di scegliere la destinazione, il repository e il profilo. Se vuoi un’installazione minimale, la modalità personalizzata è quella che evita di portarti dietro tutto il metapacchetto. Se invece vuoi una macchina pronta a compilare documenti eterogenei senza pensieri, la installazione completa è più semplice da mantenere, ma occupa di più.
Durante l’installazione, il punto chiave è il path finale. Una configurazione tipica termina in qualcosa come /usr/local/texlive/2024 o /usr/local/texlive/2025. L’anno reale dipende dalla release che stai installando, non dalla versione Debian.
Configurare PATH, MANPATH e INFOPATH senza sporcare il sistema
Il binario non serve a nulla se non è nel PATH. La pratica migliore è creare uno snippet dedicato in /etc/profile.d/ per l’uso di sistema, oppure un file nel profilo dell’utente se la macchina è condivisa ma non vuoi esporre TeX Live a tutti. Per ambienti server, lo snippet globale è spesso più chiaro.
sudo tee /etc/profile.d/texlive.sh > /dev/null <<'EOF'
export PATH=/usr/local/texlive/2024/bin/x86_64-linux:$PATH
export MANPATH=/usr/local/texlive/2024/texmf-dist/doc/man:$MANPATH
export INFOPATH=/usr/local/texlive/2024/texmf-dist/doc/info:$INFOPATH
EOF
Adatta l’anno e l’architettura al tuo caso. Su Debian 11 e 12 su x86_64 il binario è normalmente sotto x86_64-linux. Dopo aver creato lo snippet, ricarica la sessione o fai un source per il test rapido.
source /etc/profile.d/texlive.sh
which pdflatex
pdflatex --versionSe vuoi un controllo ancora più rigoroso, verifica che il primo elemento del PATH sia davvero quello della release installata. È il modo più semplice per evitare che un vecchio /usr/bin vinca la precedenza su una nuova installazione.
Installazione minimale o completa: come decidere
La scelta non è teorica. Una installazione completa ti evita problemi quando un documento usa pacchetti poco comuni, ma aumenta tempi e spazio. Una installazione minimale è più elegante in ambienti controllati, ma richiede disciplina: quando manca un pacchetto, devi aggiungerlo in modo esplicito.
Se gestisci una workstation personale o una macchina di build, la via di mezzo funziona bene: installazione base più pacchetti aggiunti solo quando il progetto li richiede. In pratica, parti da un set piccolo e lasci che siano i log di compilazione a dirti cosa manca.
pdflatex documento.texSe compare un errore del tipo “File `xyz.sty' not found”, non significa che TeX Live sia rotto: significa che il documento dipende da un pacchetto non presente. Il rimedio corretto è installare il pacchetto mancante con tlmgr, non cercare workaround nel sorgente del documento finché non hai capito il gap reale.
Per una macchina di team, conviene documentare i pacchetti aggiunti manualmente. Senza questa lista, dopo qualche mese non distingui più la base standard dalle dipendenze speciali del tuo workflow.
Uso di tlmgr: pacchetti, repository e aggiornamenti
tlmgr è il gestore dei pacchetti di TeX Live e va usato con una regola: una sola sorgente di verità. Se hai installato Vanilla, lascia a tlmgr il compito di mantenere l’albero TeX Live. Non mischiare aggiornamenti manuali e pacchetti Debian sullo stesso albero.
tlmgr option repository https://mirror.ctan.org/systems/texlive/tlnet
sudo tlmgr update --self --allPer verificare cosa è installato, usa il listing dei pacchetti e la versione del manager. È utile anche per capire se l’installazione è rimasta allineata alla release corrente.
tlmgr version
tlmgr list --only-installed | head
Se l’aggiornamento fallisce, il primo controllo è la connettività verso il repository e il proxy, se presente. Il secondo è lo spazio su disco. Il terzo è il permesso sul tree di installazione: se non hai privilegi coerenti, tlmgr non può scrivere dove deve.
In ambienti dove il repository deve essere congelato per ripetibilità, puoi puntare a uno snapshot o a un mirror interno. È una scelta utile su CI e build farm, perché elimina la variabilità del giorno.
Convivenza con i pacchetti Debian: meglio evitare ambiguità
La convivenza è possibile, ma va gestita con attenzione. Se lasci installati i pacchetti TeX di Debian e aggiungi Vanilla, il rischio non è solo estetico: il sistema può risolvere binari da un albero e file di supporto da un altro, con errori difficili da leggere.
Il controllo minimo è vedere quale binario viene eseguito e quale formato di file di formato usa. Il check del PATH non basta se hai wrapper o alias locali.
type -a pdflatex
kpsewhich article.cls
kpsewhich geometry.stySe kpsewhich punta ai file sotto /usr/local/texlive, sei nella strada giusta. Se punta a percorsi Debian mentre il binario è quello Vanilla, hai una configurazione mista e va chiarita prima di usarla in produzione.
La soluzione più pulita, quando vuoi standardizzare, è rimuovere i pacchetti TeX Debian non necessari o isolare l’uso di Vanilla a utenti e job specifici. Non fare pulizia drastica senza inventario: prima elenca i pacchetti installati e verifica cosa dipende da cosa.
dpkg -l | grep -E '^ii\s+texlive|^ii\s+latex'
Verifiche post-installazione che evitano ore di debug
Una installazione buona non si misura dal fatto che pdflatex --version restituisca qualcosa, ma dal fatto che compili un documento reale senza ambiguità. Il test minimo deve coprire motore, font e formato PDF.
cat > /tmp/test-texlive.tex <<'EOF'
\documentclass{article}
\usepackage[utf8]{inputenc}
\begin{document}
TeX Live Vanilla su Debian.
\end{document}
EOF
pdflatex -interaction=nonstopmode -halt-on-error /tmp/test-texlive.tex
Se il file PDF viene generato e il log non mostra errori di ricerca pacchetti, il circuito base è sano. A quel punto puoi provare anche xelatex o lualatex se il tuo workflow li usa.
xelatex -interaction=nonstopmode -halt-on-error /tmp/test-texlive.tex
lualatex -interaction=nonstopmode -halt-on-error /tmp/test-texlive.tex
Se uno di questi motori fallisce ma pdflatex no, il problema non è l’installazione base: è la dipendenza specifica del motore o del documento. La differenza è importante perché ti evita di reinstallare tutto senza motivo.
Aggiornamento annuale e rollback pratico
TeX Live ha un ciclo annuale. Questo significa che, prima o poi, l’albero installato va sostituito con una nuova release. La strategia pulita è affiancare la nuova versione, testarla, poi spostare il PATH e solo dopo ritirare la vecchia. È il modo più semplice per avere rollback reale.
La procedura è più sicura se tratti la nuova installazione come un change controllato: prima installi in una directory separata, poi verifichi i documenti critici, infine aggiorni i riferimenti di sistema. Se qualcosa non torna, basta rimettere il PATH alla release precedente.
ls -l /usr/local/texlive/
Il rollback non deve essere improvvisato: se hai modificato /etc/profile.d/texlive.sh, conserva una copia del file precedente. Se hai utenti con profili custom, verifica che non abbiano hardcoded il vecchio anno nel PATH.
Quando la vecchia release non serve più, puoi rimuoverla con cautela. Prima però assicurati che nessun job automatico o utente la stia ancora usando. In ambienti condivisi, la dismissione va annunciata e verificata con un inventario minimo dei binari ancora referenziati.
Errori tipici e lettura corretta dei sintomi
Un errore frequente è confondere problemi di installazione con problemi di permessi. Se tlmgr non aggiorna, non partire dal presupposto che il repository sia rotto: controlla prima il path, il proprietario dell’albero e la disponibilità di spazio.
Un altro caso classico è il binario giusto con librerie sbagliate nel contesto del terminale. Questo succede quando si entra in shell non login, in ambienti grafici o via strumenti che non leggono /etc/profile.d/. In quel caso il problema non è TeX Live, ma il punto in cui carichi il PATH.
Infine c’è il tema dei font. Se il documento compila su una macchina e fallisce su un’altra, non dare per scontato che il motore sia identico: controlla i pacchetti font installati, il file log e il risultato di kpsewhich. TeX Live è molto coerente, ma solo se il tuo albero lo è altrettanto.
Scelta pratica finale su Debian 11 e 12
Se vuoi un setup che sia prevedibile, aggiornabile e allineato all’ecosistema TeX, TeX Live Vanilla è la strada giusta anche su Debian 11 e 12. La regola è trattarlo come software esterno gestito da te, non come un pacchetto qualunque del sistema. Quando lo fai, ottieni un ambiente più stabile per build, documentazione tecnica e flussi editoriali.
La parte davvero importante non è l’installer in sé, ma la disciplina operativa: un solo albero attivo, PATH esplicito, aggiornamenti controllati, verifica con documenti reali e rollback pronto. Con questi quattro punti, l’installazione smette di essere un esercizio e diventa infrastruttura affidabile.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.