Re: Encore une question sur les transitions de libs
* Pierre THIERRY <nowhere.man@levallois.eu.org> [2006-01-26 22:22] :
> Scribit Steve Langasek dies 23/01/2006 hora 01:33:
> > Dans quelle sense sont-ils "paquets de transition"?
>
> Si j'ai bien compris, une fois la transition terminée, des paquets
> entreront l'archive sans le suffixe, non ? J'en viens d'ailleurs à une
Non, pas nécessairement. Les paquets de bibliothèque conservent le
dernier nom utilisé lors de la transition et les paquets pré-transition
sont supprimés. Un ancien nom de paquet ne peut être réutilisé dans Sid
que quand il n'est présent que dans Woody (car les transitions Woody ->
Etch sont non supportées).
> question que j'aurais du poser depuis longtemps : existe-t-il une
> documentation sur les méthodes de transitions de bilbiothèques dans
> Debian ?
Pas à ma connaissance, la difficulté est que chaque transition est
plutôt spécifique (il y a eu les grandes transitions C++, mais il y a
souvent de petites transitions de bibliothèque moins importantes). Tu
peux consulter les différents courriels de la liste
debian-devel-announce, par exemple
http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html pour
des infos sur la première transition C++ après la publication de Sarge.
> S'il n'y en a pas, j'aimerais beaucoup aider à la rédiger.
>
> > Et il est déjà assez difficile de réaliser une telle transition sans
> > faire des corrections aux descriptions de paquet au même temps.
>
> Ne faut-il pas déjà modifier le fichier control pour changer les
> dépendances ? Cela couterait-il vraiment beaucoup de rajouter une ligne
> dans le champ Description ?
J'avoue ne pas voir l'intérêt pour l'utilisateur (auquel est destiné la
description) de savoir qu'une bibliothèque est issue d'une transition,
ce n'est utile que pour les développeurs Debian au moment de la
transition. Pour savoir de quelle transition il s'agit, il est possible
soit d'analyser le nom du paquet (le "c2a") ou de lire le
changelog.Debian.gz du paquet.
> Quelque chose du genre :
>
> Package: kdelibs4c2a
> Version: 4:3.4.3-2
> Description: core libraries for all KDE applications
> This package contains all the shared libraries used by all KDE
> applications. You need these libraries to run KDE applications.
> .
> This package is part of KDE, and a component of the KDE libraries
> module. See the 'kde' and 'kdelibs' packages for more information.
> .
> This is the kdelibs4 package for the C++ new allocator transition.
>
> Peut-être avec une URI où est la transition est expliquée en détails :
>
> This is the kdelibs4 package for the C++ new allocator transition. See
> http://www.debian.org/devel/transitions/c2a for more informations.
Ce n'est pas le rôle du champ Description.
> > Tenez compte que pour ceux qui installent etch, la "transition" n'a rien à
> > voir; ils sont simplement les versions courrants des bibliothèques...
>
> Oui, mais la présence de paquets qui ne sont pas encore passés aux
> dépendences de la transition rend soit les nouveaux soit les anciens
> impossibles à installer (puisque kdelibs4c2a est en conflit avec
> kdelibs4 et kdelibsc2).
Cela est géré par le script (britney) qui s'occupe de générer testing.
En effet, les 2 paquets kdelibs4c2 et kdelibs4c2a ne peuvent pas être
présents en même temps (à cause de conflit sur les paquets) et les
paquets dépendants de la dernière version de la bibliothèque ne pourront
rentrer dans testing que quand tous les paquets en dépendance auront été
recompilés. C'est pour cela que testing reçoit les paquets par paquets
et que certains paquets sont parfois supprimés de testing (pour éviter
de bloquer des transitions problématiques).
Pour les utilisateurs de Sid, eh bien, ce sont les risques associés à
l'utilisation d'unstable.
> Pendant les deux dernières transitions, aptitude, lorsque je lançais un
> upgrade ou installait certains nouveaux paquets, me proposait de
> supprimer une énorme partie de mes paquets installés, à cause de cela.
> J'étais forcé, pour mettre quand même à jour ma machine, de mettre à
> jour les paquets un à un, manuellement, pour ne mettre à jour que ceux
> qui ne causaient pas de conflit.
Unstable, je suppose ? Tu aurais pu bloquer les applications que tu ne
voulais pas voir disparaître, cela aurait automatiquement bloquer les
bibliothèques qui te posaient problème.
Fred
Reply to: