On est bien d'accord que dans les cas simples, où une application n'utilise qu'une version de la bibliothèque, il suffit de distribuer les anciennes versions de la bibliothèque. Encore faut-il le faire. Si une application A utilise LibFoo 1.0 et que LibFoo 2.0 la remplace comme unique version installée dans les nouvelles distros, les développeurs de A vont être submergés de plaintes de clients même si "il suffit de faire apt-get install libfoo-1". Il faut distribuer les anciennes versions par défaut, avec les nouvelles, pour que la sortie de la nouvelle soit réellement indolore pour l'ancienne, tant qu'elle a des utilisateurs.
Ensuite il y a les cas plus complexes où une application a besoin des 2 versions simultanément, non pas parce que ses développeurs sont tordus, mais typiquement parce que parmi les autres bibliothèques qu'elle utilise, certaines sont déjà passées à LibFoo2 et d'autres pas encore. Un exemple de ça est ce que j'ai mentionné dans le journal: les plugins utilisant GTK2 et ne pouvant pas se déplacer dans un processus séparé (Java). De nombreux autres exemples, je suppose, sont à trouver dans les applications de bureau libre où la tradition est de lier dynamiquement à un grand nombre de bibliothèques externes. Dans tous ces cas, en cas de cassure de la compatibilité binaire, en plus de distribuer les anciennes versions, il faut que les différentes versions soient utilisables simultanément.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -2.
On est bien d'accord que dans les cas simples, où une application n'utilise qu'une version de la bibliothèque, il suffit de distribuer les anciennes versions de la bibliothèque. Encore faut-il le faire. Si une application A utilise LibFoo 1.0 et que LibFoo 2.0 la remplace comme unique version installée dans les nouvelles distros, les développeurs de A vont être submergés de plaintes de clients même si "il suffit de faire apt-get install libfoo-1". Il faut distribuer les anciennes versions par défaut, avec les nouvelles, pour que la sortie de la nouvelle soit réellement indolore pour l'ancienne, tant qu'elle a des utilisateurs.
Ensuite il y a les cas plus complexes où une application a besoin des 2 versions simultanément, non pas parce que ses développeurs sont tordus, mais typiquement parce que parmi les autres bibliothèques qu'elle utilise, certaines sont déjà passées à LibFoo2 et d'autres pas encore. Un exemple de ça est ce que j'ai mentionné dans le journal: les plugins utilisant GTK2 et ne pouvant pas se déplacer dans un processus séparé (Java). De nombreux autres exemples, je suppose, sont à trouver dans les applications de bureau libre où la tradition est de lier dynamiquement à un grand nombre de bibliothèques externes. Dans tous ces cas, en cas de cassure de la compatibilité binaire, en plus de distribuer les anciennes versions, il faut que les différentes versions soient utilisables simultanément.