Bon, bah vous vous en doutez, ça n'a finalement rien donné (trop peu d'exemples pour en tirer quoique ce soit). Snif...

Vous utilisez pas ce genre d'outils, ou vous avez pas trop connaissance de ces "problèmes" de compatibilité ?

Je n'utilise pas ces outils, et je n'ai pas trop connaissance de ces problèmes non plus... désolé!

Qu'est-ce que vous utilisez pour gérer les paquets logiciels dans vos déploiements en général ? Directement des outils liés à l'OS (apt, yum/dnf, homebrew, ...) ?

Pour l'os j'utilise apt, pour le dev j'utilise composer et les gestionnaires de node (même si j'évite nodejs comme la peste).

Oui, les installations de logiciel compilés manuellement auxquelles je peux avoir à faire même customs passent par le package manager (apt, yum, portage). Ce n'est jamais très long d'écrire un .spec file ou un ebuild ou autre pour que les désinstallations se passent bien ensuite.

Il y a des exceptions, notamment quelques modules perl souvent installés via cpan. Pour les applis web, si le projet est bien géré j'ai tendance à maintenir l'appli via git (par exemple pour roundcube ou miniflux).

Et dans le cas de Composer / CPAN, vous avez déjà rencontré des soucis particuliers ? Comme des dépendances non-satisfaites, ou un build non-déterministe, ou... ?

Pour rebondir sur le .spec file, est-ce que vous fixez les versions requises dans ce fichier, ou vous avez des contraintes de dépendances plus "souples" ?

Jamais rencontré de soucis avec CPAN.
Sinon quand j'écris un package j'utilise autant que possible des dépendances souples, si pas d'erreur de build je laisse la contrainte la plus large possible pour éviter d'avoir à perdre du temps à revenir sur le paquet à l'avenir.

Ok, merci

Quand tu parles de contraintes "souples", tu utilises une simple borne inférieure, je suppose (e.g. >=2.3.1) ?
Si oui, et si je peux me permettre encore quelques questions :
- Comment choisis-tu cette version ? Pour ma part, c'est souvent la "dernière version disponible au moment où je teste", mais si le projet a pour but d'être distribué, et pour éviter le "dependency hell", il faut parfois être moins "exigeant", non ?
- Comment vérifies-tu qu'une version ultérieure est encore compatible ? Est-ce que tu as un CI qui t'en informe (les tests crashent -> changement incompatible dans une dépendance ?) Et dans ce cas, comment réagis-tu ? Tu modifies la contrainte pour éviter ces "nouvelles versions incompatibles" (e.g. >=2.3.1 & <3.0.0) ou tu adaptes ton projet pour qu'il soit compatible avec la nouvelle version, et tu mets à jour la contrainte (e.g. >=3.0.0) ?
- Agis-tu différemment en fonction du paquet dont tu as besoin ? Je veux dire : si tu sais que le paquet a typiquement des mises à jour incompatibles, est-ce que tu as plutôt tendance à utiliser une contrainte plus stricte (e.g. =2.3.1) à la place ?

Merci pour tes réponses

Concernant mon utilisation de composer, je laisse la dernière version majeure disponible mais il m'est arrivé de devoir downgrader à cause d'une dépendance fixée en dure dans l'une de mes dépendances justement.
A part cela, pas de soucis particuliers. En général je ne m'arrête pas une version données afin de profiter des dernières évolutions, jusqu'à ce que ça fasse planter le programme évidemment. Là je suis obligé de fixer la dernière version fonctionnelle.

Ok, donc c'est plutôt une approche réactive Merci ;)

Oui, je définie bien en borne inférieure la version courrante de la distribution, mais en enlevant les révisions de patch. Je garde truc-majeur.mineur, j'enlève ce qu'il peut y avoir après.

Je ne teste pas avec une CI, je n'en ai encore jamais vu l'intérêt pour les quelques paquets que je compile. Je suis admin système et réseau, pas développeur : si un paquet est cassé, je le saurais parce que la supervision des machines en production le remontera. Vu que les quelques trucs que je compile sont quasiment tous liés au monitoring, cela me convient bien. Je n'ai jamais de problème de dependency hell car ce sont des dépendances de base genre openssl>=1.1.0 ou libssh >= 0.8, perl >= 5.18... jamais des trucs haut niveau qui bougent beaucoup.