Re: Boost version

[Sébastien Dinot <sebastien.dinot@free.fr>]

Pierre Couderc a écrit :
> merci, cela devrait marcher mais ce n'est pas une solution
> satisfaisante , en particulier si je "livre" ce programme sur un autre
> PC  (où je n'aurai pas besoin libboost-xxx-dev).

Dans ce cas, il faudra juste déclarer une dépendance à libboost-xxx1.62.

> J'espère que le problème est dans mon build (meson) ou j'ai rajouté
> "version>=1.62", j'espère que cela fonctionnera au prochaine "apt
> upgrade"....

Cette déclaration de dépendance dans Meson permet au développeur de
vérifier que l'environnement requis pour compiler l'outil est bien
conforme, mais il n'assure nullement qu'un exécutable compilé avec la
version 1.62 fonctionnera avec la version 1.74.

On se trouve là face à un dilemme vieux comme les systèmes
d'exploitation ou presque, sachant qu'il existe deux stratégies opposées
et que chacune a ses forces et ses faiblesses :

1. Créer, comme le font les systèmes MS-Windows et MacOS, mais aussi les
   outils tels que Docker, Snap ou AppImage, des paquets auto-portants
   (i.e. qui contiennent toutes les bibliothèques et ressources dont
   a besoin l'application pour fonctionner).

2. Créer, comme le fait tout système Unix, des outils compilés de
   manière homogène pour la cible considérée, ce qui leur permet de se
   satisfaire des versions des bibliothèques déployées nativement sur le
   système cible.

La stratégie 1 est pratique pour le développeur (il se libère des
contingences du système), mais introduit une énorme faille de sécurité :
on peut patcher le système d'exploitation sans que cela ait le moindre
effet sur l'application et donc, sans que cela corrige les failles de
sécurité. En outre, on surconsomme de l'espace disque et en mémoire
vive, mais qui se soucie de ce détail à l'heure du conteneur roi.

La stratégie 2 est pratique pour l'admin. sys. car le patch du système
d'exploitation corrige le problème au niveau de toutes les applications
et la consommation de disque et de mémoire vive est optimisée. Mais
cette stratégie est une vraie plaie pour tout développeur créant une
application multi-cible (et là, je ne parle même pas de MS-Windows ou de
MacOS, mais juste des différentes distributions GNU/Linux dans leurs
différentes versions).

La stratégie 1 est en train de l'emporter sur la 2 et donc, les
développeurs sur les admin. sys., avec la promesse que les
conteneurisations de toute sorte créeront des espaces isolés qui ne
permettront pas aux failles de sécurité de s'étendre au delà de
l'application qui les engendre. Certains semblent se contenter de cet
état de fait. J'y vois pour ma part un danger sérieux, car elle déporte
la charge de la veille sécuritaire sur les développeurs, qui ne s'en
soucient généralement pas (qui parmi les développeurs abonnés à cette
liste est abonné à une liste d'annonce de CVE et surveille les failles
affectant les bibliothèques qu'il utilise ? Probablement personne).

Sébastien


-- 
Sébastien Dinot, sebastien.dinot@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !