❦ 30 janvier 2013 00:07 CET, Jérôme BEAREL <jbea...@astelcom.fr> :
>> Pour quel(s) raison(s) est-il préférable de compiler les sources
>> plutôt de d'utiliser un gestionnaire de paquet?
> Autant les mainteneurs des paquets font un super boulot autant tu n'as
> pas la maitrise de la version et des patchs qui sont dans cette
> version.
C'est la seule raison qui me semble valable pour ne pas utiliser le
paquet de la distrib, à condition de vouloir effectivement une version
différente avec des patchs particuliers.
> -Pour un POC ça ne pose aucun problème, j'aurais même tendance à dire
> que c'est la bonne méthode par contre en production et surtout en
> centre d'appel il y a intérêt à savoir que l'usage de telle fonction
> avec telle autre en simultané provoque un deadlock du chan_sip (au
> hasard) dans la version x.y sans le patch zzz par exemple.
> Et ça, ce n'est pas pas dans l'apt-cache show asterisk mais dans la
> validation de la version déployée.
C'est typiquement le genre de trucs qui a plus de chance d'être corrigé
dans une version packagée qui a été testée par un quelques centaines de
personnes dans le cadre de la distrib (tel compileur, telle libc) qu'en
prenant telle version depuis les sources et en étant le seul à
utiliser une combinaison particulière.
> -Les gestionnaires de paquets en mettent partout dans le fs certes en
> respectant la nomenclature de l'arborescence mais du coup c'est pas
> simple pour installer une xème version en parallèle et faire une mise
> en production ou un rollback par changement d'un lien symbolique.
apt-get install asterisk=version-qui-marche
> -Pour passer un patch c'est juste l'application du patch et/ou la
> modification des sources + trois lignes de commandes pour mettre en
> service.
Dis comme ça, on croirait que chaque machine de prod est installée avec
des outils de développement.
> -Un apt-get upgrade hasardeux peut avoir des conséquences
> "inattendus", dans le meilleurs des cas, un simple contournement du
> problème dans le dialplan fera le job, dans le pire des cas, le
> comportement des API de type AMI ou AGI auront un comportement
> différents et les softs de CTI auront un comportement aléatoire.
Ce qui est fort peu probable si on suit une branche stable d'une
distribution (type Debian stable, Ubuntu LTS) puisqu'il n'y a justement
aucune montée en version autorisée, juste des patchs ciblés qui fixent
des deadlocks dans chan_sip.
D'une manière générale, il est assez curieux de faire confiance à la
distribution pour des composants aussi critiques que la libc, gcc ou le
noyau et de penser que pour des paquets comme Asterisk, ils ne sont pas
capables de fournir le même boulot.
On peut considérer (à raison) que l'on n'est mieux placé que le
mainteneur du paquet pour savoir quelle est la version la plus adaptée
d'Asterisk à ses besoins et donc utiliser sa propre version, mais de là
à dire qu'il faut absolument compiler depuis les sources si on veut pas
passer pour un guignol...
--
printk("Illegal format on cdrom. Pester manufacturer.\n");
2.2.16 /usr/src/linux/fs/isofs/inode.c
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
