Bonjour,
J'ai Aurox 10.1.
J'ai Perl V5.8.3.
Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas
de rpm -U.
Comment faut-il faire pour, de façon générale, upgrader une application
qui n'est pas rpm ?
Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met
le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde
tout ce qui tourne avec...
Alors, quand rpm -U n'est pas utilisable, comment faire ?
merci pour vos réponses et bon après-midi,
Dominique
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
noone
Bonjour, J'ai Aurox 10.1. J'ai Perl V5.8.3. Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas de rpm -U. Comment faut-il faire pour, de façon générale, upgrader une application qui n'est pas rpm ? Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde tout ce qui tourne avec... Alors, quand rpm -U n'est pas utilisable, comment faire ? merci pour vos réponses et bon après-midi, Dominique
attendre que ça arrive en paquet pour ta distrib...
Il apporte quoi ton nouveau Perl par rapport à l'ancien ?
Bonjour,
J'ai Aurox 10.1.
J'ai Perl V5.8.3.
Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas
de rpm -U.
Comment faut-il faire pour, de façon générale, upgrader une application
qui n'est pas rpm ?
Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met
le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde
tout ce qui tourne avec...
Alors, quand rpm -U n'est pas utilisable, comment faire ?
merci pour vos réponses et bon après-midi,
Dominique
attendre que ça arrive en paquet pour ta distrib...
Il apporte quoi ton nouveau Perl par rapport à l'ancien ?
Bonjour, J'ai Aurox 10.1. J'ai Perl V5.8.3. Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas de rpm -U. Comment faut-il faire pour, de façon générale, upgrader une application qui n'est pas rpm ? Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde tout ce qui tourne avec... Alors, quand rpm -U n'est pas utilisable, comment faire ? merci pour vos réponses et bon après-midi, Dominique
attendre que ça arrive en paquet pour ta distrib...
Il apporte quoi ton nouveau Perl par rapport à l'ancien ?
LiNuCe
dominique:
Bonjour,
Bonjour,
J'ai Aurox 10.1. J'ai Perl V5.8.3. Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas de rpm -U. Comment faut-il faire pour, de façon générale, upgrader une application qui n'est pas rpm ? Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde tout ce qui tourne avec... Alors, quand rpm -U n'est pas utilisable, comment faire ? merci pour vos réponses et bon après-midi, Dominique
Je vous conseillerais plutôt de garder la version du logiciel spécialement intégrée dans votre distribution, ou alors d'attendre que l'éditeur de celle-ci fournisse une mise à jour officielle. Certaines distributions, tel que Linux Mandrake par exemple, dépendent réellement de PERL pour leurs outils d'administration et de configuration : à mon avis, il me semble très sage de ne pas tenter l'aventure d'une mise à jour hasardeuse.
Une solution plus "propre" serait de vérifier sur le site de l'auteur/éditeur du logiciel que vous souhaitez mettre à jour pour voir s'il contient un paquetage spécialement conçu pour votre distribution. Sinon il existe aussi des dépôts RPM qui fournissent divers logiciels mis à jour pour diverses distributions.
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse, consiste à utiliser la fameuse suite de commande "./configure --prefix=/dossier ; make ; make install". En cas de problème de logiciels qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi traffiqué.
En résumé, pour tenter une mise à jour avec des paquetages/solutions tierces (comprendre non issues par l'éditeur de votre distribution), il faut *vraiment* avoir *la* bonne raison qui le nécessite.
-- LiNuCe
dominique:
Bonjour,
Bonjour,
J'ai Aurox 10.1.
J'ai Perl V5.8.3.
Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas
de rpm -U.
Comment faut-il faire pour, de façon générale, upgrader une application
qui n'est pas rpm ?
Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met
le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde
tout ce qui tourne avec...
Alors, quand rpm -U n'est pas utilisable, comment faire ?
merci pour vos réponses et bon après-midi,
Dominique
Je vous conseillerais plutôt de garder la version du logiciel
spécialement intégrée dans votre distribution, ou alors d'attendre que
l'éditeur de celle-ci fournisse une mise à jour officielle. Certaines
distributions, tel que Linux Mandrake par exemple, dépendent réellement de
PERL pour leurs outils d'administration et de configuration : à mon avis,
il me semble très sage de ne pas tenter l'aventure d'une mise à jour
hasardeuse.
Une solution plus "propre" serait de vérifier sur le site de
l'auteur/éditeur du logiciel que vous souhaitez mettre à jour pour voir
s'il contient un paquetage spécialement conçu pour votre distribution.
Sinon il existe aussi des dépôts RPM qui fournissent divers logiciels mis à
jour pour diverses distributions.
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse,
consiste à utiliser la fameuse suite de commande "./configure
--prefix=/dossier ; make ; make install". En cas de problème de logiciels
qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous
pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers
installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi
traffiqué.
En résumé, pour tenter une mise à jour avec des paquetages/solutions
tierces (comprendre non issues par l'éditeur de votre distribution), il
faut *vraiment* avoir *la* bonne raison qui le nécessite.
J'ai Aurox 10.1. J'ai Perl V5.8.3. Une version plus récente est dans les tuyaux mais pas en rpm. Donc pas de rpm -U. Comment faut-il faire pour, de façon générale, upgrader une application qui n'est pas rpm ? Quand il n'y a qu'un logiciel, c'est simple; On vire l'ancien et on met le nouveau. Avec perl, ça me semble hasardeux de retirer à la hussarde tout ce qui tourne avec... Alors, quand rpm -U n'est pas utilisable, comment faire ? merci pour vos réponses et bon après-midi, Dominique
Je vous conseillerais plutôt de garder la version du logiciel spécialement intégrée dans votre distribution, ou alors d'attendre que l'éditeur de celle-ci fournisse une mise à jour officielle. Certaines distributions, tel que Linux Mandrake par exemple, dépendent réellement de PERL pour leurs outils d'administration et de configuration : à mon avis, il me semble très sage de ne pas tenter l'aventure d'une mise à jour hasardeuse.
Une solution plus "propre" serait de vérifier sur le site de l'auteur/éditeur du logiciel que vous souhaitez mettre à jour pour voir s'il contient un paquetage spécialement conçu pour votre distribution. Sinon il existe aussi des dépôts RPM qui fournissent divers logiciels mis à jour pour diverses distributions.
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse, consiste à utiliser la fameuse suite de commande "./configure --prefix=/dossier ; make ; make install". En cas de problème de logiciels qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi traffiqué.
En résumé, pour tenter une mise à jour avec des paquetages/solutions tierces (comprendre non issues par l'éditeur de votre distribution), il faut *vraiment* avoir *la* bonne raison qui le nécessite.
-- LiNuCe
Ronald
Le Sun, 06 Mar 2005 15:55:28 +0100, LiNuCe a écrit :
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse, consiste à utiliser la fameuse suite de commande "./configure --prefix=/dossier ; make ; make install". En cas de problème de logiciels qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi traffiqué.
Surtout que perl ne suit pas le schéma classique, c'est plutôt qqchose comme: $sh Configure -Dprefix=/chemin -de et sans uninstall il me semble.
Le Sun, 06 Mar 2005 15:55:28 +0100, LiNuCe a écrit :
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse,
consiste à utiliser la fameuse suite de commande "./configure
--prefix=/dossier ; make ; make install". En cas de problème de logiciels
qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée,
vous pourrez toujours essayer le "make uninstall" pour désinstaller les
fichiers installés, suivit d'un mise à jour forcée du paquetage du
logiciel ainsi traffiqué.
Surtout que perl ne suit pas le schéma classique, c'est plutôt qqchose
comme: $sh Configure -Dprefix=/chemin -de et sans uninstall il me semble.
Le Sun, 06 Mar 2005 15:55:28 +0100, LiNuCe a écrit :
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse, consiste à utiliser la fameuse suite de commande "./configure --prefix=/dossier ; make ; make install". En cas de problème de logiciels qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi traffiqué.
Surtout que perl ne suit pas le schéma classique, c'est plutôt qqchose comme: $sh Configure -Dprefix=/chemin -de et sans uninstall il me semble.
LiNuCe
Ronald:
Le Sun, 06 Mar 2005 15:55:28 +0100, LiNuCe a écrit :
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse, consiste à utiliser la fameuse suite de commande "./configure --prefix=/dossier ; make ; make install". En cas de problème de logiciels qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi traffiqué.
Surtout que perl ne suit pas le schéma classique, c'est plutôt qqchose comme: $sh Configure -Dprefix=/chemin -de et sans uninstall il me semble.
Raison de plus :) Et c'est tout à fait possible et à vrai dire, ça ne m'étonnerait pas vu la relative "complexité" de PERL à installer quand on le compare avec les autres logiciels plus standard" à installer.
En fait, dans mon message précédent, j'ai été volontairement assez générique pour qu'il s'applique aux mises à jours en général - sauf évidemment le passage précisant l'utilisation de PERL par les outils de configuration & d'administration de Linux Mandrake.
-- LiNuCe
Ronald:
Le Sun, 06 Mar 2005 15:55:28 +0100, LiNuCe a écrit :
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse,
consiste à utiliser la fameuse suite de commande "./configure
--prefix=/dossier ; make ; make install". En cas de problème de logiciels
qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée,
vous pourrez toujours essayer le "make uninstall" pour désinstaller les
fichiers installés, suivit d'un mise à jour forcée du paquetage du
logiciel ainsi traffiqué.
Surtout que perl ne suit pas le schéma classique, c'est plutôt qqchose
comme: $sh Configure -Dprefix=/chemin -de et sans uninstall il me semble.
Raison de plus :) Et c'est tout à fait possible et à vrai dire, ça ne
m'étonnerait pas vu la relative "complexité" de PERL à installer quand on
le compare avec les autres logiciels plus standard" à installer.
En fait, dans mon message précédent, j'ai été volontairement assez
générique pour qu'il s'applique aux mises à jours en général - sauf
évidemment le passage précisant l'utilisation de PERL par les outils de
configuration & d'administration de Linux Mandrake.
Le Sun, 06 Mar 2005 15:55:28 +0100, LiNuCe a écrit :
Enfin, la dernière solution, celle qui est *vraiment* hasardeuse, consiste à utiliser la fameuse suite de commande "./configure --prefix=/dossier ; make ; make install". En cas de problème de logiciels qui ne fonctionneraient plus suite à une mise à jour ainsi effectuée, vous pourrez toujours essayer le "make uninstall" pour désinstaller les fichiers installés, suivit d'un mise à jour forcée du paquetage du logiciel ainsi traffiqué.
Surtout que perl ne suit pas le schéma classique, c'est plutôt qqchose comme: $sh Configure -Dprefix=/chemin -de et sans uninstall il me semble.
Raison de plus :) Et c'est tout à fait possible et à vrai dire, ça ne m'étonnerait pas vu la relative "complexité" de PERL à installer quand on le compare avec les autres logiciels plus standard" à installer.
En fait, dans mon message précédent, j'ai été volontairement assez générique pour qu'il s'applique aux mises à jours en général - sauf évidemment le passage précisant l'utilisation de PERL par les outils de configuration & d'administration de Linux Mandrake.
-- LiNuCe
LiNuCe
dominique:
En résumé, pour tenter une mise à jour avec des paquetages/solutions tierces (comprendre non issues par l'éditeur de votre distribution), il faut *vraiment* avoir *la* bonne raison qui le nécessite.
En fait, il me faut bien avouer que c'était plus la curiosité qu'autre chose qui m'animait. Je suis loin d'avoir le niveau en Perl pour apprécier une telle mise à jour de la 5.8.3 à la 5.8.6 !
En résumé, sorti de rpm -i ou -U, il n'y a pas de salut pour des applications complexes comme Perl, par exemple, ou des applications assez lourdes comme ImageMagick ?
Oui voilà, je pense qu'il vaut mieux être prudent et conserver les logiciels de sa distribution favorite, à moins de vraiment savoir ce qu'on fait, comment le faire ou comment faire des paquetages pour sa distribution (l'idéal pour bénéficier des avantages d'un gestionnaire de paquetage).
Sinon une méthode simple est d'installer les logiciels dans le dossier /usr/local (./configure --prefix=/usr/local) afin qu'ils n'entrent pas en conflit avec ceux de votre distribution : l'arborescence /usr/local est dédiée à cela et n'est pas modifiée par les paquetages de votre distribution. Il faut penser à ajouter le dossier /usr/local/bin dans votre variable d'environnement $PATH, à ajouter le dossier /usr/local/lib dans le fichier /etc/ld.so.conf, et éventuellement à ajouter /usr/local/man dans votre variable d'environnement $MANPATH. Ainsi, si vous installer de cette façon le logiciel "vim" et qu'il est aussi présent dans votre distribution, l'invocation de "vim" utilisera d'abord la version que vous avez installé dans /usr/local. Cependant, en procédant ainsi, vous ne bénéficierez évidemment pas des commodités du gestionnaire de paquetage de votre distribution pour mettre à jour les logiciels ainsi installés.
Enfin, il existe une autre méthode qui consiste à installer les logiciels dans leur propre dossier ("à la Windows") : c'est ce que propose le projet STOW :
http://www.gnu.org/software/stow/
Cette solution est beaucoup moins simple que la précédente. Mais en contrepartie, elle est beaucoup plus pratique qu'une installation sauvage car il est possible de gérer l'installation de ses logiciels favoris avec un programme dédié (stow), un peu comme vous le faites avec le gestionnaire de paquetage de votre distribution. Pour la petite anecdote, STOW nécessite ... PERL :)
-- LiNuCe
dominique:
En résumé, pour tenter une mise à jour avec des paquetages/solutions
tierces (comprendre non issues par l'éditeur de votre distribution), il
faut *vraiment* avoir *la* bonne raison qui le nécessite.
En fait, il me faut bien avouer que c'était plus la curiosité qu'autre
chose qui m'animait. Je suis loin d'avoir le niveau en Perl pour
apprécier une telle mise à jour de la 5.8.3 à la 5.8.6 !
En résumé, sorti de rpm -i ou -U, il n'y a pas de salut pour des
applications complexes comme Perl, par exemple, ou des applications
assez lourdes comme ImageMagick ?
Oui voilà, je pense qu'il vaut mieux être prudent et conserver les
logiciels de sa distribution favorite, à moins de vraiment savoir ce qu'on
fait, comment le faire ou comment faire des paquetages pour sa distribution
(l'idéal pour bénéficier des avantages d'un gestionnaire de paquetage).
Sinon une méthode simple est d'installer les logiciels dans le
dossier /usr/local (./configure --prefix=/usr/local) afin qu'ils n'entrent
pas en conflit avec ceux de votre distribution : l'arborescence /usr/local
est dédiée à cela et n'est pas modifiée par les paquetages de votre
distribution. Il faut penser à ajouter le dossier /usr/local/bin dans votre
variable d'environnement $PATH, à ajouter le dossier /usr/local/lib dans le
fichier /etc/ld.so.conf, et éventuellement à ajouter /usr/local/man dans
votre variable d'environnement $MANPATH. Ainsi, si vous installer de cette
façon le logiciel "vim" et qu'il est aussi présent dans votre distribution,
l'invocation de "vim" utilisera d'abord la version que vous avez installé
dans /usr/local. Cependant, en procédant ainsi, vous ne bénéficierez
évidemment pas des commodités du gestionnaire de paquetage de votre
distribution pour mettre à jour les logiciels ainsi installés.
Enfin, il existe une autre méthode qui consiste à installer les logiciels
dans leur propre dossier ("à la Windows") : c'est ce que propose le projet
STOW :
http://www.gnu.org/software/stow/
Cette solution est beaucoup moins simple que la précédente. Mais en
contrepartie, elle est beaucoup plus pratique qu'une installation sauvage
car il est possible de gérer l'installation de ses logiciels favoris avec
un programme dédié (stow), un peu comme vous le faites avec le gestionnaire
de paquetage de votre distribution. Pour la petite anecdote, STOW
nécessite ... PERL :)
En résumé, pour tenter une mise à jour avec des paquetages/solutions tierces (comprendre non issues par l'éditeur de votre distribution), il faut *vraiment* avoir *la* bonne raison qui le nécessite.
En fait, il me faut bien avouer que c'était plus la curiosité qu'autre chose qui m'animait. Je suis loin d'avoir le niveau en Perl pour apprécier une telle mise à jour de la 5.8.3 à la 5.8.6 !
En résumé, sorti de rpm -i ou -U, il n'y a pas de salut pour des applications complexes comme Perl, par exemple, ou des applications assez lourdes comme ImageMagick ?
Oui voilà, je pense qu'il vaut mieux être prudent et conserver les logiciels de sa distribution favorite, à moins de vraiment savoir ce qu'on fait, comment le faire ou comment faire des paquetages pour sa distribution (l'idéal pour bénéficier des avantages d'un gestionnaire de paquetage).
Sinon une méthode simple est d'installer les logiciels dans le dossier /usr/local (./configure --prefix=/usr/local) afin qu'ils n'entrent pas en conflit avec ceux de votre distribution : l'arborescence /usr/local est dédiée à cela et n'est pas modifiée par les paquetages de votre distribution. Il faut penser à ajouter le dossier /usr/local/bin dans votre variable d'environnement $PATH, à ajouter le dossier /usr/local/lib dans le fichier /etc/ld.so.conf, et éventuellement à ajouter /usr/local/man dans votre variable d'environnement $MANPATH. Ainsi, si vous installer de cette façon le logiciel "vim" et qu'il est aussi présent dans votre distribution, l'invocation de "vim" utilisera d'abord la version que vous avez installé dans /usr/local. Cependant, en procédant ainsi, vous ne bénéficierez évidemment pas des commodités du gestionnaire de paquetage de votre distribution pour mettre à jour les logiciels ainsi installés.
Enfin, il existe une autre méthode qui consiste à installer les logiciels dans leur propre dossier ("à la Windows") : c'est ce que propose le projet STOW :
http://www.gnu.org/software/stow/
Cette solution est beaucoup moins simple que la précédente. Mais en contrepartie, elle est beaucoup plus pratique qu'une installation sauvage car il est possible de gérer l'installation de ses logiciels favoris avec un programme dédié (stow), un peu comme vous le faites avec le gestionnaire de paquetage de votre distribution. Pour la petite anecdote, STOW nécessite ... PERL :)
-- LiNuCe
dominique
En résumé, pour tenter une mise à jour avec des paquetages/solutions tierces (comprendre non issues par l'éditeur de votre distribution), il faut *vraiment* avoir *la* bonne raison qui le nécessite.
En fait, il me faut bien avouer que c'était plus la curiosité qu'autre chose qui m'animait. Je suis loin d'avoir le niveau en Perl pour apprécier une telle mise à jour de la 5.8.3 à la 5.8.6 !
En résumé, sorti de rpm -i ou -U, il n'y a pas de salut pour des applications complexes comme Perl, par exemple, ou des applications assez lourdes comme ImageMagick ?
Merci et bonne soirée, Dominique
En résumé, pour tenter une mise à jour avec des paquetages/solutions
tierces (comprendre non issues par l'éditeur de votre distribution), il
faut *vraiment* avoir *la* bonne raison qui le nécessite.
En fait, il me faut bien avouer que c'était plus la curiosité qu'autre
chose qui m'animait. Je suis loin d'avoir le niveau en Perl pour
apprécier une telle mise à jour de la 5.8.3 à la 5.8.6 !
En résumé, sorti de rpm -i ou -U, il n'y a pas de salut pour des
applications complexes comme Perl, par exemple, ou des applications
assez lourdes comme ImageMagick ?
En résumé, pour tenter une mise à jour avec des paquetages/solutions tierces (comprendre non issues par l'éditeur de votre distribution), il faut *vraiment* avoir *la* bonne raison qui le nécessite.
En fait, il me faut bien avouer que c'était plus la curiosité qu'autre chose qui m'animait. Je suis loin d'avoir le niveau en Perl pour apprécier une telle mise à jour de la 5.8.3 à la 5.8.6 !
En résumé, sorti de rpm -i ou -U, il n'y a pas de salut pour des applications complexes comme Perl, par exemple, ou des applications assez lourdes comme ImageMagick ?
