Si tu l'installes, comme c'est souvent le cas par defaut, sous /usr/local, il y a moindre mal dans la mesure ou tu as pris soin de desinstaller l'eventuel rpm binaire qui faisait le meme office avant.
Exemple typique : Apache sur RH. rpm -e (en mettant de cote peut-etre le script de demarrage/stop sous /etc/rc.d/init.d histoire de l'adapter plus tard ;-) ) et ensuite une reinstallation du tar.gz et ./configure "d'origine" ou presque sous /usr/local/src.
Idem pour d'autres softs qui evoluent vite (PostgreSQL ou PHP par exemple).
Il est sur que dans ce cas, il faut etre rompu aux arcanes des recompilations de tout ca en meme temps.
On en arrive a quelquechose de plus propre, avec un "core" de la distribution qui evolue en rpm et quelquechose de plus personnel sur lequel on veut avoir plus de prise (ou reactivite quant a la disponibilite des dernieres moutures...) sous /usr/local/.
De ce que j'ai vu de ma rapide incursion sous FreeBSD, c'est un peu organise de la sorte (et avis personnel, c'est plus propre).
Pour le reste, les tar.gz comportent souvent un fichier .spec qu'il suffit eventuellement d'adapter pour le cas personnel et un rpm -ta <tarball> permet de regenerer a partir des sources le rpm source, binaire qui va bien.
La gestion de package est de toute facon l'element essentiel pour qu'une distribution tienne la route. Sans ca, ca devient ingerable et on perd plus de temps a bricoler et a rendre le systeme pourri non pas seulement en termes de fonctionnalites mais aussi de maintenance.
Meme Microsoft l'a pige maintenant en reinstallant des DLL essentielles au systeme eventuellement sur des DLL qui viennent d'etre installees par une appli, ce afin de conserver l'integrite du systeme parfois au depend du bon fonctionnement d'une appli.
Apres tout, il est surement plus important d'avoir la base installee de l'OS propre qu'un truc qui merde parce que les applis installees ont aide a le veroler. Ceci est valable au moins sous sous Windows 2000 mais aussi sur Linux ou autre, gere par les pre et post installations qui sont des elements essentiels des gestionnaires de package, avec la gestion de signature (cf intervention precedente).
Voir l'excellent bouquin disponible en ligne sur les fonctionnalites des RPM : http://www.rpm.org/(...) chapitre Documentation, disponible au format PostScript ou LaTeX. Interessant pour comprendre la gestion de packages.
[^] # Re: vive les tarballs
Posté par Anonyme . En réponse à la dépêche Quel avenir pour RPM ?. Évalué à 0.
Exemple typique : Apache sur RH. rpm -e (en mettant de cote peut-etre le script de demarrage/stop sous /etc/rc.d/init.d histoire de l'adapter plus tard ;-) ) et ensuite une reinstallation du tar.gz et ./configure "d'origine" ou presque sous /usr/local/src.
Idem pour d'autres softs qui evoluent vite (PostgreSQL ou PHP par exemple).
Il est sur que dans ce cas, il faut etre rompu aux arcanes des recompilations de tout ca en meme temps.
On en arrive a quelquechose de plus propre, avec un "core" de la distribution qui evolue en rpm et quelquechose de plus personnel sur lequel on veut avoir plus de prise (ou reactivite quant a la disponibilite des dernieres moutures...) sous /usr/local/.
De ce que j'ai vu de ma rapide incursion sous FreeBSD, c'est un peu organise de la sorte (et avis personnel, c'est plus propre).
Pour le reste, les tar.gz comportent souvent un fichier .spec qu'il suffit eventuellement d'adapter pour le cas personnel et un rpm -ta <tarball> permet de regenerer a partir des sources le rpm source, binaire qui va bien.
La gestion de package est de toute facon l'element essentiel pour qu'une distribution tienne la route. Sans ca, ca devient ingerable et on perd plus de temps a bricoler et a rendre le systeme pourri non pas seulement en termes de fonctionnalites mais aussi de maintenance.
Meme Microsoft l'a pige maintenant en reinstallant des DLL essentielles au systeme eventuellement sur des DLL qui viennent d'etre installees par une appli, ce afin de conserver l'integrite du systeme parfois au depend du bon fonctionnement d'une appli.
Apres tout, il est surement plus important d'avoir la base installee de l'OS propre qu'un truc qui merde parce que les applis installees ont aide a le veroler. Ceci est valable au moins sous sous Windows 2000 mais aussi sur Linux ou autre, gere par les pre et post installations qui sont des elements essentiels des gestionnaires de package, avec la gestion de signature (cf intervention precedente).
Voir l'excellent bouquin disponible en ligne sur les fonctionnalites des RPM : http://www.rpm.org/(...) chapitre Documentation, disponible au format PostScript ou LaTeX. Interessant pour comprendre la gestion de packages.