[gull] L'horreur des dépendances

Marc SCHAEFER schaefer at alphanet.ch
Wed Jul 26 13:11:06 CEST 2006


On Wed, Jul 26, 2006 at 12:51:02PM +0200, Leopoldo Ghielmetti wrote:
> > Votre distribution n'intégre pas ImageMagick comme package supporté ?
>   ^^^^^
>    Ta :-)

ok :)

> Oui, mais j'ai installé beaucoup d'autres applications (c'est une
> station de travail et de loisir et pas un serveur) et apt m'a
> automatiquement upgrade toutes les librairies et les applications pour
> résoudre les dépendances. Cette résolution à impliqué la suppression de
> ImageMagick car la librairie n'était plus présente dans les versions
> plus récentes des applicatifs et ceci à impliqué que maintenant je ne
> peux plus installer d'autres applicatifs que j'aimerais avoir.

Oui, c'est le comportement correct. Tu as apparemment mis à jour
quelques bibliothèques à une version ultérieure à ce qu'OpenSuSE 10.0
fournit.  Il faut donc maintenant trouver une version d'ImageMagick qui
soit compatible.

> Ah, j'ai oublié de spécifier qu'il s'agit d'une OpenSuSE 10.0 avec dans
> sources.list une grosse liste de sites supplémentaires. Je sais que

C'est le problème effectivement. Si ces `sites' ne gèrent pas leurs
packages de manière compatible avec OpenSuSE 10.0, le problème existe.
C'est comme si dans une Debian stable tu ajoutes tout à coup des sources
de testing, puis mets à jours une partie des packages.

La seule façon simple et correcte de s'en sortir est de supprimer toutes
les sources de stable, mettre testing et mettre à jour ... quelques
100MB par jour.

Debian (et apt) incorporent la notion de pinning (choix de versions
différentes de bibliotèques), et *certains* packages peuvent exister en
plusieurs versions simultanée (p.ex. PostgreSQL), notamment pour
faciliter la migration, mais c'est loin d'être le cas de tous les
packages.

> 1) ce sont les seuls qui proposent les paquetages qui m'intéressent et
> de cette façon j'ai l'installation par apt et les upgrades aussi sans
> devoir à chaque fois aller rechercher les rpm qui vont bien avec leur
> dépendances.

oui, mais.

Tu as violé la règle de cohérence. Ta distribution est maintenant
composée de bouts de machins d'un peu partout.  Si au moins tu avais
utilisé le pinning, les dégâts seraient un peu moins importants.

Si tu tiens absolument à des versions récentes de logiciels, les
méthodes correctes sont:

   - prendre une distribution qui évolue vite (p.ex. Debian testing)
     inconvénient: fréquentes mises à jour, risque de casse

   - prendre une distribution stabilisée (p.ex. Debian ou Ubuntu stable)
     et ajouter une source de `backports' -- des packages plus récents
     relativement compatibles avec une version ancienne de la
     distribution

> 2) il suffirait qu'il y ait une philosophie commune pour la création et
> l'utilisation des librairies et le tour serait joué.

non, ce n'est pas possible.

Certains changements upstream (p.ex. glibc) sont incompatibles, et il
serait terriblement compliqué, peu sûr et finalement peu fiable d'avoir
toutes les versions disponibles.

PS: il faut aussi considérer que les packages RPM, *même gérés via APT*,
ne *contiennent pas* toutes les informations que Debian considère
nécessaires à la gestion ...

> Il y a aussi d'autres problèmes qui m'ont obligé à utiliser l'option
> force que tu n'aimes pas, simplement car le paquetage A définissait le
> fichier titi-toto.mime et le paquetage B aussi, chose qui empêche
> d'installer en même temps A et B bien que les deux soient parfaitement
> compatibles. Normalement titi-toto.mime devrait être installé que par A
> mais pour des questions de facilité ils ont du en mettre une copie aussi
> dans B pour ceux qui installent B sans installer A (les deux fichiers
> sont parfaitement identiques).

Debian crée alors un package supplémentaire C, qui contient
titi-toto.mime et que A et B incluent dans leurs dépendances. Il est
bien sûr impossible de garantir cela si le gestionnaire des packages
n'est pas une unique et seule entité.

Ceci est un bug de distribution, qui ne justifie pas l'utilisation de
--force à long terme.

Sauf erreur (mais je n'ai pas regardé récemment), ce genre de bugs sont
détectés automatiquement lors d'une release Debian (un fichier installé
au même endroit par deux packages qui ne sont pas incompatibles dans les
dépendances). Voir
http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.1

> Donc impossible d'installer les deux sans forcer.

Si tu fais ce genre de chose, il est indispensable de mettre les deux
packages en `hold' (chose à ma connaissance impossible sous RPM) de
manière à ce que le système ne touche plus à ces deux packages ...
en particulier pas de mise à jour automatique.





More information about the gull mailing list