Personnellement, sur ma LFS, pour le genre de programme que vous décrivez, à savoir ceux qui sont susceptibles d'être régulièrement mis à jours, j'applique l'une des deux solutions suivante :
- Soit : ./configure --prefix=/usr/local/nom_du_programme Le désavantage de cette méthode, c'est qu'au final, on a un $PATH un peu long :) (et les autres variable d'environnements aussi, ainsi que d'autres fichiers de configuration comme /etc/ld.so.conf où il faut à chaque fois rajouter le path vers les librairies qui vont bien )
- Soit je reutilise les mêmes paramêtres de configuration que l'original pour la mise à jour, (souvent dans le config.log, il suffit alors de garder ce fichier dans un coin), en espérant que ca ecrasera convenablement l'ancien. Ou alors, on peut récupérer les anciennes sources, refaire un configure, et faire un make uninstall si les sources implémentent l'option.
Il y a surement d'autres solutions encore plus propres, mais je ne les connais pas! :)
[^] # Re: Reste le problème des upgrades
Posté par Raphael Berlamont (site web personnel) . En réponse à la dépêche LFS 5.1 dans les bacs. Évalué à 3.
- Soit : ./configure --prefix=/usr/local/nom_du_programme Le désavantage de cette méthode, c'est qu'au final, on a un $PATH un peu long :) (et les autres variable d'environnements aussi, ainsi que d'autres fichiers de configuration comme /etc/ld.so.conf où il faut à chaque fois rajouter le path vers les librairies qui vont bien )
- Soit je reutilise les mêmes paramêtres de configuration que l'original pour la mise à jour, (souvent dans le config.log, il suffit alors de garder ce fichier dans un coin), en espérant que ca ecrasera convenablement l'ancien. Ou alors, on peut récupérer les anciennes sources, refaire un configure, et faire un make uninstall si les sources implémentent l'option.
Il y a surement d'autres solutions encore plus propres, mais je ne les connais pas! :)