Discussion :

[yacinechaouche]

Bonjour,

Supposons que je veuille installer une application A qui demande une nouvelle version de la librairie L. Impossible de mettre à jour cette librairie sans risque de casser tout le système car des dizaines d'autres librairies en dépendent.

Est-ce que des outils comme jailkits permettent de créer un environnement où les nouvelles librairies (L et ses dépendances) seraient installées dans un répertoire à part dans lequel je pourrais chrooter pour lancer l'application A ? Ou bien est-ce nécessaire d'utiliser un app container comme docker pour créer une sorte de machine virtuelle ?

Merci pour vos suggéstions.

[gangsoleil]

Bonjour,

Je suppose que tu es sous Linux, donc la réponse courte est non.

En effet, le principe de la librairie partagée est justement qu'il n'y ait qu'une seule instance de cette librairie qui soit présente à la fois sur la machine. Dans la vraie vie, ma_lib.so est en fait un lien vers ma_lib.so.version, ce qui te permet d'avoir plusieurs versions existantes sur la machine, mais tu n'en as qu'une seule d'active, ma_lib.so.

Solution 1 : linker A avec ma_lib.so.version
C'est crade, pas portable, et ca t'assure que si A change de version, le simple fait de le mettre à jour va tout casser, car tu vas oublier d'updater L.

Solution 2 : linker A avec ma_lib.a
Les librairies statiques sont effectivement une solution, mais s'il faut profiter d'un update de la lib, ça nécessite de faire un update de A.

Solution 3 : déployer A dans une VM

Solution 4 : chroot. Je ne pense pas que ce soit suffisant, car tu vas avoir besoin de déployer L dans /lib, puis de monter ce répertoire dans ton chroot. Néanmoins, il existe peut-être un moyen, je ne m'en sers pas assez.

Solution 5 : utiliser la variable LD_LIBRARY_PATH : elle permet de forcer le chemin dans lequel les applications vont chercher leurs lib. ATTENTION, car cette variable d'environnement s'applique à tous les programmes que tu lanceras dans cet environnemnt.
Utilisation : tu poses L dans /mon/chemin/pour/la/lib/pourrie/, puis tu définies LD_LIBRARY_PATH=/mon/chemin/pour/la/lib/pourrie/ Ensuite, tu lances A depuis ce terminal, hop, il ira voir dans ce repertoire.
Du coup, tu peux faire un script chapeau, que tu appelles A.sh :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#!/bin/ksh
LD_LIBRARY_PATH=/mon/chemin/pour/la/lib/pourrie/
export LD_LIBRARY_PATH
/chemin/vers/A

[yacinechaouche]

Merci gangsoleil. Si le linker fonctionne comme le reste avec les variables d'environnement, je devrais donc simplement ajouter le chemin spécifique (disons /usr/local/lib) devant le chemin standard (/usr/lib) afin qu'il soit lu en premier. Ca permettra de trouver le reste des librairies du système (libc6 etc.) Ça donnerais quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export LD_LIBRARY_PATH=/usr/local/lib/:/usr/lib/

[gangsoleil]

Oui, mais attention : si tu fais ça pour tous les executables, c'est comme si tu mettais ta lib dans /usr/lib. D'où mon conseil d'utiliser un script de lancement, ou bien un utilisateurs spécifique, ou n'importe quel autre méthode qui te permet de n'avoir /usr/local/lib que dans le cas qui t'intéresse.