[gull] apt & Suse...

[Marc SCHAEFER]

On Wed, Mar 09, 2005 at 04:23:51PM +0100, Daniel Cordey wrote:
> Sauf si l'on sait pourquoi... (ET c'est parfois necessaire) En l'occurence 
> j'ai installe mysql et apache2.0 sur mon systeme... mais en tarball, pas a 
> partir de RPMs. En general, je fais aussi la meme chose avec xine-lib que je 

Dans ce cas, je recommanderais la création d'un package stub vide non
désinstallable (marqué comme hold si ça existe avec les RPMs) ayant
comme description la documentation de l'installation locale et dépendant
des bibliothèques et autres programmes utilisés par l'application
installée localement.

En cas de mise à jour incompatible de packages, le système de packaging
voudra alors désinstaller mon package stub et je serai informé. Même si
c'est dans 2 ans, il suffira de lire la description du package pour se
souvenir: ah oui etc.

Ou je créerais mon propre package avec les binaires du logiciel installé
localement, p.ex. en backport d'une version plus récente. En nommant la
version du package de façon claire.

Exemple: j'aime bien déployer Asterisk, mais la version distribuée avec
la Debian (même instable) n'est pas assez récente à mon goût, de plus
j'aime y ajouter des patches standards et des patches personnels. Je
prends le package de Debian, je change sa version, je change le
changelog, j'applique les patches, je régénère et j'installe.

Ca donne quelque chose comme:

   schaefer at shakotay:~$ dpkg -s asterisk
   Package: asterisk
   Status: install ok installed
   Priority: optional
   Section: comm
   Installed-Size: 3636
   Maintainer: Marc SCHAEFER <schaefer at alphanet.ch>
   Version: 1:1.0.6-0.bristuff_0.2.0_RC7k.cril.0

On peut d'ailleurs automatiser largement ce processus (p.ex. pour
Apache, je maintiens des patches séparés et je regénère le package à
chaque mise à jour de sécurité de Debian stable).

On peut aussi déposer ce package sur un serveur de packages de manière à
permettre à tous les clients de mettre à jour (en cas de problème de
sécurité p.ex.).

S'il s'agit d'une application propriétaire qui est absolument
nécessaire, on informe le client de la non viabilité à long terme de la
chose, puis on crée un package ad-hoc, probablement en `hold'.

Ou on installe dans /usr/local/PROPRIETARY/nom-application-version et on crée
les scripts de lancement dans /usr/local/bin (ce qui a comme avantage de
permettre l'installation simultanée de plusieurs versions, le
basculement par changement de liens symboliques ou des scripts de
lancement, voire en fonction du nom de la machine en cas d'installation
réseau NFS).

Jusqu'ici je n'ai jamais dû faire d'équivalent de --nodeps en production.