[gull] L'horreur des dépendances

[Leopoldo Ghielmetti]

On Wed, 2006-07-26 at 13:11 +0200, Marc SCHAEFER wrote:
> 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.

Exact. Et malheureusement cette librairie n'existe pas. Et revenir en
arrière ça implique rechercher plein de packages à réinstaller. Donc je
reste en attente que le ImageMagick soit aussi adapté ou qu'une
librairie plus récente intègre les fichiers manquants.

> > 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.

Oui, mais après bonjour les dégâts quand on a besoin d'un logiciel et
que malheureusement à ce moment la il ne marche pas et qu'il faut
attendre une semaine pour avoir une version de nouveau en état de
marche. Chose que d'ailleurs est partiellement en train de m'arriver
avec evolution, mais ses problèmes ne sont pas liés à la version que
j'ai actuellement mais à toutes les suivantes. Ils ont fait une bourde
et cassé la compatibilité exchange, il y a pas mal de plaintes sur le
net.

> 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.

Avec les rpm on peut aussi installer plusieurs versions d'un logiciel,
mais les deux paquetages doivent être compatibles sinon il n'accepte que
l'upgrade.

> > 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.

Probablement, mais le pinning je ne le connais pas je ne travail qu'avec
les rpm et le pinning n'existe pas ou au moins pas comme sur la Debian
je supposes.

> 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

A étudier.

> > 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.

Pas si sûr.

> 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.

pour les librairies normalement il ont un numéro de version libc.so.2,
libc.so.3, libc.so.4, ...
Il suffit qu'un logiciel vérifie d'avoir une version qui lui convient et
c'est fini.
Si jamais t'a la libc.so.4 et le logiciel veut la .5 tu l'installes en
parallèle avec la .4, les autres utiliseront toujours la .4 et le
nouveau logiciel la .5.
Au fond c'est bien pour ça qu'on a inventé les numéros de version sur
les librairies non? sinon il suffisait de les appeler toutes libc.so et
ne mettre la version qu'a l'intérieur du fichier. à ce moment ou la
librairie est bonne ou elle est mauvaise et si tu la remplace la plupart
de programmes ne marchent plus.

Si les choses avaient été faites correctement on n'aurait jamais du
avoir de problèmes de versions de librairies.

Pour ce qui est des ressources système elles sont mises à disposition
par le noyau, donc même en remplaçant la librairie elles devraient
toujours marcher.

Je comprends que si on change la version du noyau on peut avoir des
incompatibilités car à ce moment les ressources système ne sont plus
forcement compatibles, mais pour les librairies user space on ne
devraient pas avoir a jouer avec ces incompatibilités.

> 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 ...

Je ne connais pas les deux formats dans le détail bien que j'utilise le
rpm depuis des années.
A ma connaissance le format rpm est assez bon, mais si je connaissait à
fond les deux peut être que je dirais que le format deb est meilleur. Si
je trouve le temps je vais voir d'apprendre comment ils marchent en peu
plus dans le détail.

> > 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é.

Exactement. Et malheureusement on ne peut pas faire grand chose dans ce
cas la, sauf utiliser "force".

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

bug de distribution si les packages viennent de la même source, bug de
coherence s'ils viennent de sources différentes. Dans l'exemple
précédent le package B n'a à priori pas de raison valable d'installer le
fichier titi-toto.mime vu que normalement ce serait uniquement A qui en
a besoin. Ou alors le package B doit regarder si un fichier avec le même
nom existe et ne pas essayer de l'installer. Au fond B l'installe
uniquement car si A n'est pas la le type titi-toto ne serait pas connu
par l'interface graphique et donc on ne verrait pas la jolie icône. Mais
si le package A est la alors la fonctionnalité de titi-toto est complète
et le package B n'a plus besoin de fournir titi-toto.mime.

> 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

Oui, mais est-ce qu'il remplace le fichier du module A ou celui du
module B? dans mon cas le fichier de A est normalement prioritaire,
qu'on installe A avant ou après B. Donc si on installe B suivi de A le
fichier doit être remplacé, si on installe A suivi de B il doit être
ignoré. Il faudrait qu'il gère une priorité et non simplement un
"Replace".

> > 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.

Je crois que au contraire c'est possible. Vu que j'utilise apt je peux
ajouter des lignes dans son config pour lui dire de ne pas mettre à jour
le package qui m'intéresse. Le problème c'est que le package en question
est déjà mis à jour. :-P

Merci pour les remarques, c'est enregistré et je vais sûrement jeter un
coup d'oeil au formats de package rpm et deb (par contre ce ne sera pas
pour tout de suite car je suis déjà débordé). :-(

ciao, Leo