Discussion :

[renlobkk]

Bonjour

J'ai compilé php-5.2.15 avec apache-2.2.17 sur mon pc qui tourne sur Fedora-14, mais quelques jours après ma compilation, php à sortis une nouvelle version 5.2.16 et je souhaite maintenant mettre à jour mon installation vers une des deux version sus-mentionnées.

Comme il s'agit d'une version compilée, je souhaite pauser la question dans ce forum s'il existe une procédure de mise à jour php
cest-à-dire :

1. avant de pouvoir mettre mon installation à jour version php 5.2.16 ou 5.3.4, est-ce qu'il est nécessaire de désinstaller la version précédemment compilée "5.2.15" ? et si oui, qu'elle est la commande pour désinstaller cette version, car j'ai essayé "make uninstall" mais impossible j'obtient un message d'erreur


2. existe t'il une commande de mise à jour de php pour une version compilée, sans utiliser "yum install php" ou "yum update"
si oui, qu'elle est-elle, car j'ai cherché des heures mais je n'ai rien trouvé ?

Merci d'avance pour vos réponses

sincèrement
renlo

[julp]

1) non, il faut le faire à la "main"
2) non. Et c'est justement l'intérêt des gestionnaires de paquets comme yum que d'installer des paquets binaires (voir sources) et de pouvoir, entre autres, faire ça eux-même (sans parler de la gestion des dépendances).

[renlobkk]

merci pour votre réponse julp,
je ne comprend pas pourquoi dans beaucoup de livre sur php, il recommende une insatllation compilée en nous disant qu'ainsi on est plus libre sur le modules à installer. Si après il est "pratiquement" impossible de la mettre à jour, ca n'en vaut pas la peine, mieux vaut utiliser yum

Juste une dernière question:
Est-ce qu'il est possible de remedier à ce problème en utilisant un prefix pour le dossier d'installation de php "exemple: /home/renlo/myphp/" ?
puis effacer complètement le dossier d'installation lorsqu'on veut mettre php à jour ?

Merci d'avance pour votre réponse
a+
renlo

[julp]

je ne comprend pas pourquoi dans beaucoup de livre sur php, il recommende une insatllation compilée en nous disant qu'ainsi on est plus libre sur le modules à installer

C'est tout sauf mon avis. L'argument est mal choisi justement par rapport aux gestionnaires de paquet, qui tous ou presque, font de sorte à avoir une installation modulaire (extensions dynamiques) où chaque extension de PHP est un paquet à part. Il est donc aisé de se faire une installation propre à ses besoins (on s'épargne aussi la gestion des dépendances).

Par contre, savoir compiler PHP est indéniablement un plus. Surtout pour des besoins particuliers : privilégier les performances/limiter l'installation (en embarqué notamment), patcher PHP, linker PHP sur des bibliothèques précises (se passer de pcre ou sqlite bundled par exemple), etc.

Est-ce qu'il est possible de remedier à ce problème en utilisant un prefix pour le dossier d'installation de php "exemple: /home/renlo/myphp/" ?

Oui et non mais de toute façon le préfixe est /usr/local par défaut, normalement.

puis effacer complètement le dossier d'installation lorsqu'on veut mettre php à jour ?

Pas forcément, c'est ce que je voulais dire par "oui et non" ci-dessus. Il y a potentiellement des composants annexes installés ailleurs (je pense surtout au module Apache lorsque compilé avec --with-apxs(2)).

Ne surtout jamais écraser une installation par une autre, ça peut réserver des "surprises".