[gull] L'horreur des dépendances

[Marc SCHAEFER]

On Wed, Jul 26, 2006 at 09:55:42AM +0200, Thierry de Coulon wrote:
> un disque dur qui fait moins de 160 GB, ne serait-il pas temps sous linux 
> aussi de compiler plus en statique?

Cela signifie que s'il y a un bug de sécurité dans `zlib', tu dois
installer des nouvelles versions de tous les packages qui contiennent
un programme qui dépend de zlib.

En bref, plutôt qu'une petite mise à jour simple (suivi d'un redémarrage
des services dépendants), tu as un service pack de 250 MB et un risque
de déstabilisation d'applications.

Il faut aussi ajouter que tout ce qui n'est pas en shared-object prend de la
mémoire vive supplémentaire à chaque instance (programme lui-même lancé
plusieurs fois excepté).

La méthode Apple est très étonnante, car c'est un retour en arrière
d'une dizaine d'années dans l'administration système UNIX. Même Microsoft se
met aux packages d'installation (CAB/MSI).

Dans mon expérience, les systèmes de gestion de dépendance fonctionnent
*parfaitement* si:

   - on n'installe ABSOLUMENT RIEN qui n'est pas géré par eux
     (sauf dans /usr/local.  Si on installe QUOI QUE CE SOIT dans le
      système, faire une diversion (Debian only) ou créer un `dummy'
      package qui contient les fichiers, et le mettre en hold (Debian only))

   - on installe UNIQUEMENT des packages de la MEME distribution et
     version, supportés par la distribution (sinon: /usr/local)

   - on n'utilise JAMAIS; JAMAIS; JAMAIS les options `force'
     d'installation

        si on doit les utiliser c'est qu'on a commis une faute
        précédemment ou que la distribution n'est pas de bonne
        qualité

   - on lit les RELEASE NOTES avant les mises à jour.

        certains packages sont splittés, transférés, renommés, certaines
        mises à jour complexes doivent se faire dans un ordre donné.

   - on utilise la version stable d'une distribution.

Avec la méthode ci-dessus, on peut même installer des logiciels
propriétaires ou de nouvelles versions pour transition ou test.

Même lorsqu'il y a des bugs de packaging, en général on s'en sort
convenablement.  Je ne me souviens pas, depuis plus de 6 ans que
j'emploie Debian GNU/Linux stable en production sur serveurs et clients,
de cas où un bug de packaging a existé et n'était pas lié à une erreur
précédente selon la liste ci-dessus.

PS: le `trend' actuel est de packager de PLUS EN PLUS finement.