To be minimalist or not :-)
Salut,
Bon, j'expose une idée qui pourrait participer à résoudre un peu les
problèmes de rétroportage (entre autre).
Je ne reviens pas (ou si peu) sur la nécessité du rétroportage. Le
temps de latence un peu trop élevé entre deux versions stables et
officielles de Debian font que dans certains cas, le rétroportage d'un
certain nombre de paquets est une nécessité. Tout le monde ne peut pas
tourner en testing/unstable comme cela.
Or, un paquet est « designé » uniquement pour une version donnée de
Debian. Les dépendances surtout. Si bien que la mise-à-jour d'un
paquet entraîne inévitablement la mise-à-jour de la distribution par
l'intermédiaire de dépendances plus ou moins fortes qui, se cascadant,
met rapidement à jour les bases du système. Si ce processus est voulu,
et même recherché, dans le cadre homogène d'une version de Debian pour
des raisons évidentes de cohérence, c'est a contrario une plaie lors
d'un rétroportage.
En effet, lorsque l'on regarde un peu de plus près certains paquets,
on s'aperçoit rapidement que les dépendances ne sont pas
minimales. C'est là-dessus que je voudrai m'étendre un petit peu.
Tout d'abord, comme souligné au paragraphe au-dessus, j'en comprends
la nécessité (que l'on appelera l'effet cascade). On peut
difficilement migrer tout un système avec des dépendances qui
n'évoluent pas. C'est un fait et il est *indispensable* pour garder la
possibilité de migrer une distribution d'une version à une version
ultérieure.
Toutefois, il est gênant, tant d'un point de vue intellectuel (pour
introduire une dose de métaphysique) que d'un point de vue pratique
(et là, c'est pour le rétroportage) que d'être *obligé* d'aller chercher
et recompiler quelque chose de *non indispensable* à la création d'un
paquet parfaitement fonctionnel sans cela.
Techniquement, on s'en sort parfaitement en « abaissant » les numéros de
version des logiciels dépendant du paquet et on recompile. C'est une
solution bien sûr mais qui oblige à bidouiller (soit un peu au hasard en
tâtonnant un peu, soit en allant chercher les informations sur les
fichiers de compilation dans le configure). Dans tous les cas, on
modifie le paquet original, ce qui est mal puisque que l'on s'éloigne
ainsi de ce dernier, nonobstant les introductions d'erreurs dues à la
manipulation manuelle.
Bref, je propose (comme toujours dans ces cas-là) une modification de
dpkg et apt pour ajouter un (ou deux) champs dans les en-têtes des
paquets Debian. En parallèle des lignes « depends » et « suggests »,
on pourrait ajouter un « minimal depends » et « minimal suggest » (bof
pour le dernier mais cela permet d'aller au bout de la logique du
raisonnement).
Ces champs ne seraient pas activés par défaut. Un
# apt-get install toto
installerait toto avec les dépendances et suggestion (enfin, dans le
cas de dpkg :-)) du paquet toto.
Par contre, un
# apt-get install --mindep toto
tenterait d'installer toto avec comme champ de dépendance (et
suggestion pour dpkg) les champs des « minimal depends » et « minimal
suggest ».
** Quel serait l'intérêt ?
Premièrement, le paquet ne serait plus cohérent comme une entité d'une
version de Debian mais *aussi* comme une entité cohérente indépendante
(du fait qu'il contient toutes les informations inhérentes à sa propre
formation - une sorte de super paquet -).
Deuxièmement, (vous me voyez arriver avec mes gros sabots), cela
faciliterait très fortement le rétroportage « automatique » d'un grand
nombre de paquets, surtout sur des dépendances « dures » comme pour X
par exemple.
** Quels seraient les inconvénients ?
Il y en deux AMHA. Le premier est un surcoût de travail pour le
développeur puisqu'il va y avoir une recherche des dépendances
minimales à effectuer. Ce n'est pas négligeable, même si une recherche
automatique peut peut-être soulager en partie cette tache.
Le second est AHMA la pire : il faut modifier dpkg et apt. Bon, je
rigole (à moitié) mais il me semble que ce n'est pas forcément le plus
évident à (faire) faire.
J'ajoute qu'il ne faudrait pas non plus que ces champs
« relativement » secondaire soit bloquant en terme de BTS (i.e. qu'un
paquet ne soit pas admis en testing ou en stable pour un bogue
introduit suite à une erreur de ces champs). Je sais bien que c'est la
porte ouverte au laisser-aller mais étant entendu que ce n'est pas
indispensable à la stabilité de la version stable de Debian, cela ne
devrait pas être forcément bloquant. C'est à discuter (ou peut servir
de concession pour les gens qui seraient demandeurs de cette nouvelle
fonctionnalité).
Voilà, vous pouvez vous lâcher. Qu'en pensez-vous ? Et désolé si cela
a déjà été soulevé sur une des listes anglophones de Debian.
PK
--
Patrice KARATCHENTZEFF
STMicroelectronics Tel: 04-76-92-67-95
850, rue Jean Monnet
38926 CROLLES Cedex, France Courriel: patrice.karatchentzeff@st.com
Reply to: