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: [EMAIL PROTECTED]:~$ dpkg -s asterisk Package: asterisk Status: install ok installed Priority: optional Section: comm Installed-Size: 3636 Maintainer: Marc SCHAEFER <[EMAIL PROTECTED]> 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. _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
