Moi je suis plutot pour avoir le minimum de rétro-compatibilité, quand c'est possible. Quand on change quelquechose, on garde eventuellement une rétro-compatibilité pendant 1 ou 2 releases, on convertit tout le plus rapidement possible, et on se débarrasse de la rétro-compatilité des que c'est fait. Ca permet de garder les choses simples.
Et bien sache que certains y voient exactement l'inverse ! Et trouvent que c'est changer les choses qui est compliqué. Quand tu gardes des interfaces sur le long terme, ça évite d'avoir à retravailler les softs tous les quatre matins.
C'est d'ailleurs la meme raison pour laquelle les dev du noyau linux aiment avoir tous les drivers inclus directement dans l'arbre des sources du noyau: en cas de changement dans l'api interne, on modifie directement tous les drivers qui utilisent cette api, et il n'y a pas besoin de garder une compatibilité avec l'ancienne api.
Oui, effectivement : le tout est de savoir où placer les limites de stabilité. Note que l'ABI des syscall de Linux (oui, même le format binaire !) est plutôt assez stable, c'est ce qui permet par exemple à Docker de bien marcher (ça tourne sur tous les noyaux supérieurs à 3.X (j'ai oublié le X) sans se poser de questions), car un kernel se doit d'être une interface stable avec les applications utilisateur. Par contre, pour les interfaces driver-kernel, on estime que la stabilité est moins importante, car le support du matériel n'est pas considéré bon quand il est effectué en dehors de la branche principale. Oui, ce sont des jugements de valeur, les devs kernel ont tranché, et globalement ça marche plutôt pas mal comme ça.
Pour le packaging, pareil, le projet Debian a choisi les frontières de stabilité : un paquet source doit être dans un format qui change peu souvent car les outils de gestion de ces paquets sont complexes, et que faire évoluer l'ensemble des paquets de l'archive Debian est une gageure. Pour le format binaire, c'est encore « pire » : il faut potentiellement que les paquets binaires soient installables par des versions diverses et variées de dpkg et apt. Par contre, la manière pour les développeurs de gérer leurs modifications est en changement constant. Forcément, ce côté n'est pas vu par les utilisateurs : eux ne voient que le côté plutôt fixe. Et — comble de l'ironie — on a parfois des devs qui se plaignent que ça change trop pour les différentes possibilités de gestion du packaging !
Perso, la complexité n'est pas mauvaise quand elle est « simplement » dû au manque de documentation sur certaines procédures : c'est un classique du libre, ça se « corrige ». Je trouve que techniquement, les contraintes de rétro-compatibilité sont plutôt très supportables. Mais c'est clair que oui, niveau documentation, il y aurait encore des efforts à faire, même si la doc officielle est un bon début, même si elle est certes longue : non, on ne peut pas se lancer en une heure à faire un package Debian, ça demande (malheureusement ou heureusement, si on s'oriente du point de vue qualité) un peu plus d'effort.
[^] # Re: C'est l'histoire et la démocratie
Posté par benoar . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 3.
Et bien sache que certains y voient exactement l'inverse ! Et trouvent que c'est changer les choses qui est compliqué. Quand tu gardes des interfaces sur le long terme, ça évite d'avoir à retravailler les softs tous les quatre matins.
Oui, effectivement : le tout est de savoir où placer les limites de stabilité. Note que l'ABI des syscall de Linux (oui, même le format binaire !) est plutôt assez stable, c'est ce qui permet par exemple à Docker de bien marcher (ça tourne sur tous les noyaux supérieurs à 3.X (j'ai oublié le X) sans se poser de questions), car un kernel se doit d'être une interface stable avec les applications utilisateur. Par contre, pour les interfaces driver-kernel, on estime que la stabilité est moins importante, car le support du matériel n'est pas considéré bon quand il est effectué en dehors de la branche principale. Oui, ce sont des jugements de valeur, les devs kernel ont tranché, et globalement ça marche plutôt pas mal comme ça.
Pour le packaging, pareil, le projet Debian a choisi les frontières de stabilité : un paquet source doit être dans un format qui change peu souvent car les outils de gestion de ces paquets sont complexes, et que faire évoluer l'ensemble des paquets de l'archive Debian est une gageure. Pour le format binaire, c'est encore « pire » : il faut potentiellement que les paquets binaires soient installables par des versions diverses et variées de dpkg et apt. Par contre, la manière pour les développeurs de gérer leurs modifications est en changement constant. Forcément, ce côté n'est pas vu par les utilisateurs : eux ne voient que le côté plutôt fixe. Et — comble de l'ironie — on a parfois des devs qui se plaignent que ça change trop pour les différentes possibilités de gestion du packaging !
Perso, la complexité n'est pas mauvaise quand elle est « simplement » dû au manque de documentation sur certaines procédures : c'est un classique du libre, ça se « corrige ». Je trouve que techniquement, les contraintes de rétro-compatibilité sont plutôt très supportables. Mais c'est clair que oui, niveau documentation, il y aurait encore des efforts à faire, même si la doc officielle est un bon début, même si elle est certes longue : non, on ne peut pas se lancer en une heure à faire un package Debian, ça demande (malheureusement ou heureusement, si on s'oriente du point de vue qualité) un peu plus d'effort.