Dipendenze Automagic, cosa sono e come risolverle

1.  Introduzione

Cosa sono le dipendenze automagic

Le così dette dipendenze "automagic" sono dipendenze insite in un software, riconosciute all'atto della compilazione o durante l'esecuzione, che cambiano il modo in cui tale software opera. Il nome automagic è un gioco di parole riferito all'uso degli GNU autotools, che stanno dietro a molti dei casi di dipendenze automagic.

Il software normalmente possiede due tipi di dipendenze: obbligatorie e opzionali. Il primo tipo di dipendenze sono necessarie per l'utilizzo del software stesso (potrebbero rappresentare una libreria o un programma), e non possono mancare nel sistema quando si compila o esegue il programma (dipende se sono dipendenze di compilazione o di esecuzione). Le dipendenze opzionali sono tali da poter essere disabilitate, normalmente al momento della compilazione (ma talvolta anche durante l'esecuzione).

Le dipendenze opzionali vengono solitamente abilitate o disabilitate dall'utente (o dal compilatore), un esempio classico è portato dalle opzioni --enable-foo o --with-bar durante la chiamata di ./configure (questi parametri sono usati per abilitare dipendenze che sono disabilitate in modo predefinito, ma in alcuni casi potrebbero essere invece abilitate in modo predefinito e si avrà quindi --disable-foo e --without-bar).

Ma con sistemi di compilazione che provano a capire cosa è presente o meno nel sistema in cui operano, talvolta le dipendenze diventano automagic. Questo significa che il sistema di compilazione non fornisce al compilatore un modo per decidere se una data opzione deve o meno essere abilitata, pertanto viene aggiunta, ma attivata solo quando viene trovata. Questo è un comportamento sbagliato.

Perchè le dipendenze automagic sono sbagliate

Nel caso di distribuzione basate su binari, come quelle che si appoggiano su RPM o DEB, le dipendenze automagic non influiscono minimamente: se l'utente ha installato qualcosa e lo ha creato da solo, è solitamente ciò che vuole abilitare, mentre se è un manutentore, dovrà solamente aggiungere una dipendenza fra i pacchetti richiesti per eseguire il binario che ha creato.

Diverso il discorso per le distribuzioni basate su sorgenti, come Gentoo Linux (e varianti). Dal momento che la distribuzione basata su sorgenti non può distinguere utente e mantenitore del pacchetto, il sistema di compilazione potrebbe trovare più cose di quelle necessarie all'utente stesso, e proverà a collegare il software a tutto ciò che conosce a riguardo. Questa è la causa principale della rottura dei collegamenti dei binari alle librerie a seguito di una pulizia delle dipendenze inutilizzate (depclean).

Per semplificare, quando una dipendenza automagic non è indicata come obbligatoria in un ebuild, ma piuttosto possiede un flag che semplicemente aggiunge o rimuove le dipendenze su un dato pacchetto, se il pacchetto è presente nel sistema viene creato il software con le dipendenze automagic, ma se in seguito il pacchetto viene rimosso, il software risulterà corrotto, richiedendo l'esecuzione di revdep-rebuild per correggere il collegamento. È anche possibile che un utente non voglia realmente abilitare alcune dipendenze poichè sa che di tanto in tanto danno dei problemi, o perchè sta creando un pacchetto binario per un'altra macchina dove la dipendenza potrebbe non essere presente (o potrebbe non funzionare in modo corretto).

Quando un pacchetto ha una dipendenza automagic ci sono solo due cose da fare: le prima è dichiarare la dipendenza come obbligatoria, senza preoccuparsi di cosa l'utente inserisce nella propria variabile USE, ma questo potrebbe significare che alcuni supporti non desiderati dagli utenti siano sempre abilitati e che di conseguenza introducano le relative dipendenze; la seconda è correggere il sistema di compilazione in modo da renderlo capace di disabilitare al momento della compilazione la dipendenza anche se presente sul sistema.

Per molto tempo gli sviluppatori originali non hanno pensato realmente di aggiungere il supporto per disabilitare le dipendenze automagic in quanto non le ritenevano un problema concreto: le avevano tutte installate, o almeno quelle di cui necessitavano, e normalmente compilavano con tutte queste. Fortunatamente, molti degli sviluppatori originali inoltre non pensavano nemmeno di aggiungere delle opzioni per disabilitarle se venivano fornite delle patch (talvolta anche senza patch, ma certamente l'invio di patch già pronte è sempre più ben accetto), ma non è sempre così, per esempio gli sviluppatori originali di Wine non vogliono aggiungere il supporto per abilitare o disabilitare le funzionalità nella chiamata a ./configure perchè desiderano che il software usi sempre più opzioni possibili.

2.  Risolvere le dipendenze automagic

Autotools

Molte delle dipendenze automagic, come il nome suggerisce, sono dovute all'uso (scorretto) degli GNU autotools (per essere esatti autoconf). Ci sono principalmente due casi in cui le dipendenze automagic sono chiamate in causa: il primo è il caso dei "lazy devs" (sviluppatori pigri), in cui le dipendenze non hanno affatto un parametro per ./configure, bensì vengono solamente verificate con AC_CHECK_LIB o la macro PKG_CHECK_MODULES di pkg-config, che permette di eseguire codice specifico quando una libreria (o un pacchetto) è presente o meno; il secondo caso è detto "silly argument" (parametro sciocco, ridicolo), dove un parametro --disable-foo o --without-bar è effettivamente accettato da ./configure, ma non viene verificato correttamente.

Il primo caso è di norma semplice da correggere, si riduce al problema di aggiungere una chiamata AC_ARG_WITH (o AC_ARG_ENABLE) e quindi controllare la corrispondente variabile prima di effettuare il test. È utile sapere che il primo parametro passato alla precedente macro solitamente introduce una variabile che viene caricata da autoconf senza dover aggiungere parametri extra per far eseguire determinate azioni quando tale parametro è presente oppure no, la variabile viene chiama $enable_foo o $with_bar, in base a quale delle due macro viene utilizzata.

AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))

AS_IF([test "x$with_foo" != "xno"], [
  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
])

AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))

AS_IF([test "x$with_foo" = "xyes"], [
  PKG_CHECK_MODULES([FOO], [foo >= 0.1])
])

Quando il parametro è presente ma non viene rispettato, potrebbe risultare tanto semplice quanto complesso risolvere la dipendenza. Potrebbe essere solo un test scritto in modo errato, per cui bisogna apportare delle modifiche in modo simile ai test precedenti, o un completo pasticcio nelle chiamate alle macro AC_ARG_WITH. In questi casi, è meglio controllare attentamente il codice e contattare gli sviluppatori originali se sembrano esserci errori di questo livello.

Anche se è possibile aggirare il problema delle dipendenze di automagic senza modificare configure.ac, rovistando tra i valori di cache di autoconf, questo metodo non è raccomandato. Non risolve il problema originale e non può essere inviato agli sviluppatori per l'integrazione nelle prossime versioni, e potrebbe anche produrre conflitti in quanto i test sono svolti in ambienti fortemente diffenti.

CMake

Le dipendenze automagic possono presentarsi in sistemi di compilazione basati su CMake laddove venga chiamata PGK_CHECK_MODULES incondizionatamente senza il parametro REQUIRED. Sopperire a questo problema è abbastanza semplice, poiché consiste solamente nell'introduzione di un'opzione per il sistema di compilazione e per l'esecuzione di PKG_CHECK_MODULES, in base al loro valore.

OPTION(ENABLE_FOO "Enable foo library" ON)
...
IF (ENABLE_FOO)
  PKG_CHECK_MODULES (FOO foo>=0.1)
ENDIF (ENABLE_FOO)
...
IF (ENABLE_FOO)
  IF (FOO_FOUND)
  ...
  ELSE (FOO_FOUND)
  ...
  ENDIF (FOO_FOUND)
ENDIF (ENABLE_FOO)

Altri sistemi di compilazione

Le dipendenze automagic possono essere create anche con sistemi di compilazione personalizzati che vengono utilizzati da alcuni software. Sfortunatamente, essendo personalizzati, questi sistemi di compilazione sono normalmente difficili da mettere a punto, e non c'è un modo per descrivere un approccio generale per la loro risoluzione.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.