Perché non riesco a installare più versioni di una libreria condivisa?

Ci sono spesso casi in cui un certo programma dipenderà dalla versione della libreria xy e un altro dalla xz ma, per quanto ne so, nessun gestore di pacchetti mi permetterà di installare sia xy che xz A volte mi permetteranno entrambe le versioni principali (come qt4 e qt5, che possono essere installati contemporaneamente), ma (apparentemente) mai versioni minori.

Perchè è questo? Come in, qual è il fattore limitante che lo impedisce? Presumo che ci debba essere una buona ragione per non consentire questa funzionalità apparentemente utile. Ad esempio, non esiste un campo per indicare quale versione caricare quando si carica un oggetto condiviso e quindi nessun modo per Linux di sapere come decidere quale caricare? O non c'è davvero alcun motivo per questo? Come tutte le versioni minori dovrebbero essere compatibili comunque o qualcosa del genere?

In realtà, è possibile installare più versioni di una libreria condivisa se è eseguita correttamente.

Le librerie condivise sono generalmente denominate come segue:

lib<name>.so.<api-version>.<minor>

Successivamente, ci sono collegamenti simbolici alla libreria con i seguenti nomi:

lib<name>.so
lib<name>.so.<api-version>

Quando un link di sviluppo contro la libreria per produrre un binario, è il nome del file che termina in .soche i reperti linker. In effetti, può esserci solo uno di quelli installati alla volta per ogni dato, <name>ma ciò significa solo che uno sviluppatore non può targetizzare più versioni diverse di una libreria contemporaneamente. Con i gestori di pacchetti, questo .socollegamento simbolico fa parte di un -devpacchetto separato che solo gli sviluppatori devono installare.

Quando il linker trova un file con un nome che termina con .soe l'usa, si guarda dentro quella libreria per un campo chiamato soname . Il soname indica al linker quale nome file incorporare nel file binario risultante e quindi quale nome file verrà cercato in fase di esecuzione. Il soname dovrebbe essere impostato su lib<name>.so.<api-version>.

Pertanto, in fase di esecuzione, il linker dinamico lo cercherà lib<name>.so.<api-version>e lo utilizzerà.

L'intenzione è che:

• <minor>gli aggiornamenti non cambiano l'API della libreria e quando <minor>viene passata a una versione successiva, è sicuro lasciare che tutti i binari si aggiornino alla nuova versione. Dal momento che tutti i binari cercano la libreria sotto il lib<name>.so.<api-version>nome, che è un link simbolico all'ultimo installato lib<name>.so.<api-version>.<minor>, ottengono l'aggiornamento.
• <api-version>gli aggiornamenti cambiano l'API della libreria e non è sicuro lasciare che le applicazioni binarie esistenti utilizzino la nuova versione. Nel caso in cui <api-version>sia cambiato, poiché quelle applicazioni stanno cercando il nome lib<name>.so.<api-version>ma con un valore diverso per <api-version>, non preleveranno la nuova versione.

I gestori pacchetti spesso non impacchettano più di una versione della stessa libreria all'interno della stessa versione di distribuzione poiché l'intera distribuzione, inclusi tutti i file binari che utilizzano la libreria, viene generalmente compilata per utilizzare una versione coerente di ogni libreria prima che la distribuzione sia rilasciato. Assicurarsi che tutto sia coerente e che tutto in una distribuzione sia compatibile con tutto il resto è una parte importante del carico di lavoro per i distributori.

Ma puoi facilmente finire con più versioni di una libreria se hai aggiornato il tuo sistema da una versione della tua distrazione a un'altra e hai ancora dei pacchetti più vecchi che richiedono versioni di librerie più vecchie. Esempio:

• libmysqlclient16 da un vecchio Debian, contiene libmysqlclient.so.16.0.0e collegamento simbolico libmysqlclient.so.16.
• libmysqlclient18 dall'attuale Debian, contiene libmysqlclient.so.18.0.0e collegamento simbolico libmysqlclient.so.18.

Questa funzionalità non è vietata, non è molto comune a causa del modo in cui la maggior parte delle librerie funziona e per l'inconveniente delle modifiche al nome del pacchetto.

Se si utilizza uno schema di numeri di versione punteggiato XYZ La versione "micro" Z cambia spesso su correzioni di bug, il numero "minore" Y cambia su modifiche compatibili con le versioni precedenti e il numero di versione "principale" X deve cambiare su modifiche API (e talvolta lo fa su maggiori funzionalità extra).

Non ci dovrebbe mai essere un motivo per cui non si desidera correggere gli ultimi bug e nemmeno le modifiche compatibili con le versioni precedenti devono interrompere il software.

Se la libreria è sviluppata in questo modo, dovresti sempre essere in grado di sostituire XYZ con X. (Y + m). (Z + n). per ogni dato m e n. Vale a dire che dovresti sempre essere in grado di sostituire la tua libreria con le ultime della stessa serie di numeri principali. E se gli sviluppatori della biblioteca sono attenti e il prossimo numero maggiore è compatibile (ad es. Con l'annuncio di deprecare le cose, ma non rimuoverle ancora) puoi persino usare il prossimo numero maggiore.

Per gli sviluppatori di pacchetti questo significa che possono usare il nome con un solo nome o addirittura nessun nome numerico per darti l'ultima versione semplicemente aggiornando il pacchetto. Se che spediscono una biblioteca in un pacchetto abc2allora devono passare attraverso i cerchi di spostare il proprio software che si basava su abc2l'aggiornamento a uso abc3, a volte con i pacchetti di transizione. È più conveniente tralasciare il numero di versione principale da una libreria se funziona per la maggior parte dei pacchetti dipendenti. Quindi, anche se entrambi abc2e abc3dovrebbero essere disponibili ad un certo punto disponibili in una distribuzione, abc3vengono spesso chiamati abc(proprio come è abc2stato chiamato quando non c'era abc3ancora), e non appena nessun pacchetto dipende abc2dalla distribuzione diventa possibile cadereabc2 del tutto.

Lo schema di numerazione non è seguito in modo uniforme, ma posso solo immaginarlo con l'avvento di Internet che diffonde informazioni su come utilizzare tale schema e la pressione degli utenti delle biblioteche (compresi gli sviluppatori di distribuzione) di chiarire cose importanti come la compatibilità con le versioni precedenti senza dover leggere un file CHANGES incluso nella libreria, hanno contribuito a renderlo più comune.

Un esempio di contatore, ma non di una libreria, è l'intelletto di Python, che non è compatibile con i suoi oggetti condivisi e il formato di decapaggio su una variazione di numero minore. Quindi vedrai i pacchetti per Python (l'ultimo nella serie 2.7) e Python3 (l'ultimo nella serie python3.4) così come i pacchetti espliciti per Python 2.6 (non sempre meno comuni) e Python 3.3.