J'ai un Perl install=E9 dans un r=E9pertoire et je voudrais le d=E9placer=
vers un=20
autre emplacement.
Sous Windows il y a un outil "reloc_perl" qui permet de mettre =E0 jour t=
outes=20
les r=E9f=E9rences de chemin dans l'ensemble de l'installation.
Existe t'il un =E9quivalent sous Unix ou une m=E9thode simple et fiable d=
e faire=20
ce changement de chemin d'acc=E8s (Surtout simple, car la personne qui de=
vra=20
op=E9rer le changement =E0 l'autre bout du monde n'a pas invent=E9 l'eau =
chaude).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-dir=
iger=20
l'ancien chemin vers la nouvelle localisation.
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
Paul Gaborit
À (at) Mon, 08 Dec 2008 11:23:05 +0100, Nabot Leon écrivait (wrote):
J'ai un Perl installé dans un répertoire et je voudrais le déplacer vers un autre emplacement.
Sous Windows il y a un outil "reloc_perl" qui permet de mettre à jour toutes les références de chemin dans l'ensemble de l'installation.
Existe t'il un équivalent sous Unix ou une méthode simple et fiable de faire ce changement de chemin d'accès (Surtout simple, car la personne qui devra opérer le changement à l'autre bout du monde n'a pas inventé l'eau chaude).
Si perl a été compilé sans être lié à libperl (c'est une option lors de l'installation), c'est faisable tel quel (sinon il faut intervenir au niveau des l'éditeur de liens dynamique). Par contre, dans tous les cas, il faudra utiliser une variable d'environnement pour modifier @INC qui est hard-codé dans l'exécutable.
La solution propre pour éviter ces bidouilles passe par une recompilation... Ce qui n'est sans doute pas à la portée de l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à partir d'une autre machine (facilement si c'est le même système ou sinon via une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est un lien vers l'ancienne ?
Les vraies "bonnes" questions sont : quel unix utilisez-vous et pourquoi avez-vous besoin de déplacer le perl existant ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 08 Dec 2008 11:23:05 +0100,
Nabot Leon <nabotleon@N0SpamZ.hotmail.com> écrivait (wrote):
J'ai un Perl installé dans un répertoire et je voudrais le déplacer
vers un autre emplacement.
Sous Windows il y a un outil "reloc_perl" qui permet de mettre à jour
toutes les références de chemin dans l'ensemble de l'installation.
Existe t'il un équivalent sous Unix ou une méthode simple et fiable de
faire ce changement de chemin d'accès (Surtout simple, car la personne
qui devra opérer le changement à l'autre bout du monde n'a pas inventé
l'eau chaude).
Si perl a été compilé sans être lié à libperl (c'est une option lors
de l'installation), c'est faisable tel quel (sinon il faut intervenir
au niveau des l'éditeur de liens dynamique). Par contre, dans tous les
cas, il faudra utiliser une variable d'environnement pour modifier
@INC qui est hard-codé dans l'exécutable.
La solution propre pour éviter ces bidouilles passe par une
recompilation... Ce qui n'est sans doute pas à la portée de
l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à partir
d'une autre machine (facilement si c'est le même système ou sinon via
une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour
re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est
un lien vers l'ancienne ?
Les vraies "bonnes" questions sont : quel unix utilisez-vous et
pourquoi avez-vous besoin de déplacer le perl existant ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 08 Dec 2008 11:23:05 +0100, Nabot Leon écrivait (wrote):
J'ai un Perl installé dans un répertoire et je voudrais le déplacer vers un autre emplacement.
Sous Windows il y a un outil "reloc_perl" qui permet de mettre à jour toutes les références de chemin dans l'ensemble de l'installation.
Existe t'il un équivalent sous Unix ou une méthode simple et fiable de faire ce changement de chemin d'accès (Surtout simple, car la personne qui devra opérer le changement à l'autre bout du monde n'a pas inventé l'eau chaude).
Si perl a été compilé sans être lié à libperl (c'est une option lors de l'installation), c'est faisable tel quel (sinon il faut intervenir au niveau des l'éditeur de liens dynamique). Par contre, dans tous les cas, il faudra utiliser une variable d'environnement pour modifier @INC qui est hard-codé dans l'exécutable.
La solution propre pour éviter ces bidouilles passe par une recompilation... Ce qui n'est sans doute pas à la portée de l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à partir d'une autre machine (facilement si c'est le même système ou sinon via une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est un lien vers l'ancienne ?
Les vraies "bonnes" questions sont : quel unix utilisez-vous et pourquoi avez-vous besoin de déplacer le perl existant ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nabot Leon
Paul Gaborit a écrit :
La solution propre pour éviter ces bidouilles passe par une recompilation... Ce qui n'est sans doute pas à la portée de l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à part ir d'une autre machine (facilement si c'est le même système ou sinon v ia une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est un lien vers l'ancienne ?
Non, pas possible, l'ancienne installation restant en place.
Les vraies "bonnes" questions sont : quel unix utilisez-vous et pourquoi avez-vous besoin de déplacer le perl existant ?
Solaris. La raison en fait était de créer un duplicata d'une installa tion Perl existante dans un autre emplacement afin de pouvoir la bidouiller pour y ajouter certains modules exotiques. L'ancienne version utilisée par un serveur en production devant rester inchangée.
Quand à recompiler, je préfère éviter car il faudrait aussi que j e re-installe toutes les librairies qui ont servi à créer les divers modules et q ui étaient statiques. Et comme de bien entendu, ces librairies ont été supprimées depuis.
Cdlt
Léo
Paul Gaborit a écrit :
La solution propre pour éviter ces bidouilles passe par une
recompilation... Ce qui n'est sans doute pas à la portée de
l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à part ir
d'une autre machine (facilement si c'est le même système ou sinon v ia
une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour
re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est
un lien vers l'ancienne ?
Non, pas possible, l'ancienne installation restant en place.
Les vraies "bonnes" questions sont : quel unix utilisez-vous et
pourquoi avez-vous besoin de déplacer le perl existant ?
Solaris. La raison en fait était de créer un duplicata d'une installa tion Perl
existante dans un autre emplacement afin de pouvoir la bidouiller pour y
ajouter certains modules exotiques. L'ancienne version utilisée par un
serveur en production devant rester inchangée.
Quand à recompiler, je préfère éviter car il faudrait aussi que j e re-installe
toutes les librairies qui ont servi à créer les divers modules et q ui
étaient statiques. Et comme de bien entendu, ces librairies ont été supprimées
depuis.
La solution propre pour éviter ces bidouilles passe par une recompilation... Ce qui n'est sans doute pas à la portée de l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à part ir d'une autre machine (facilement si c'est le même système ou sinon v ia une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est un lien vers l'ancienne ?
Non, pas possible, l'ancienne installation restant en place.
Les vraies "bonnes" questions sont : quel unix utilisez-vous et pourquoi avez-vous besoin de déplacer le perl existant ?
Solaris. La raison en fait était de créer un duplicata d'une installa tion Perl existante dans un autre emplacement afin de pouvoir la bidouiller pour y ajouter certains modules exotiques. L'ancienne version utilisée par un serveur en production devant rester inchangée.
Quand à recompiler, je préfère éviter car il faudrait aussi que j e re-installe toutes les librairies qui ont servi à créer les divers modules et q ui étaient statiques. Et comme de bien entendu, ces librairies ont été supprimées depuis.
Cdlt
Léo
Paul Gaborit
À (at) Wed, 10 Dec 2008 17:26:09 +0100, Nabot Leon écrivait (wrote):
Paul Gaborit a écrit :
La solution propre pour éviter ces bidouilles passe par une recompilation... Ce qui n'est sans doute pas à la portée de l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à partir d'une autre machine (facilement si c'est le même système ou sinon via une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est un lien vers l'ancienne ?
Non, pas possible, l'ancienne installation restant en place.
Les vraies "bonnes" questions sont : quel unix utilisez-vous et pourquoi avez-vous besoin de déplacer le perl existant ?
Solaris. La raison en fait était de créer un duplicata d'une installation Perl existante dans un autre emplacement afin de pouvoir la bidouiller pour y ajouter certains modules exotiques. L'ancienne version utilisée par un serveur en production devant rester inchangée.
Quand à recompiler, je préfère éviter car il faudrait aussi que je re-installe toutes les librairies qui ont servi à créer les divers modules et qui étaient statiques. Et comme de bien entendu, ces librairies ont été supprimées depuis.
Ok pour le contexte qui n'est effectivement pas simple (voire risquée puisqu'il ne semble pas y avoir de serveur de test).
Une solution serait de passer par un 'chroot' ou par le truc équivalent aux jails de BSD mais pour Solaris (ça s'appel les "zones" dans OpenSolaris mais je ne me souviens plus du nom que ça portait avant). Ça permet de copier l'installation perl existante ailleurs et de lui faire croire qu'elle est toujours au même endroit.
Une autre solution (très bidouillesque et risquée) : copier les exécutables et autres bibliothèques perl et éditer à la main les chemins hardcodés (en supposant qu'ils ont la même longueur que les chemins originaux).
Reste quand même la solution que j'évoquais initialement qui consiste à utiliser la variable d'environnement PERL5LIB pour continuer à utiliser les binaires existants mais en leur permettant d'aller chercher des modules ailleurs que dans les répertoires prédéfinis. Ça devrait fonctionner puisque il n'est manifestement pas question de modifier les exécutables.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 10 Dec 2008 17:26:09 +0100,
Nabot Leon <nabotleon@N0SpamZ.hotmail.com> écrivait (wrote):
Paul Gaborit a écrit :
La solution propre pour éviter ces bidouilles passe par une
recompilation... Ce qui n'est sans doute pas à la portée de
l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à partir
d'une autre machine (facilement si c'est le même système ou sinon via
une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour
re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est
un lien vers l'ancienne ?
Non, pas possible, l'ancienne installation restant en place.
Les vraies "bonnes" questions sont : quel unix utilisez-vous et
pourquoi avez-vous besoin de déplacer le perl existant ?
Solaris. La raison en fait était de créer un duplicata d'une
installation Perl existante dans un autre emplacement afin de pouvoir
la bidouiller pour y ajouter certains modules exotiques. L'ancienne
version utilisée par un serveur en production devant rester
inchangée.
Quand à recompiler, je préfère éviter car il faudrait aussi que je
re-installe toutes les librairies qui ont servi à créer les divers
modules et qui étaient statiques. Et comme de bien entendu, ces
librairies ont été supprimées depuis.
Ok pour le contexte qui n'est effectivement pas simple (voire risquée
puisqu'il ne semble pas y avoir de serveur de test).
Une solution serait de passer par un 'chroot' ou par le truc
équivalent aux jails de BSD mais pour Solaris (ça s'appel les "zones"
dans OpenSolaris mais je ne me souviens plus du nom que ça portait
avant). Ça permet de copier l'installation perl existante ailleurs et
de lui faire croire qu'elle est toujours au même endroit.
Une autre solution (très bidouillesque et risquée) : copier les
exécutables et autres bibliothèques perl et éditer à la main les
chemins hardcodés (en supposant qu'ils ont la même longueur que les
chemins originaux).
Reste quand même la solution que j'évoquais initialement qui consiste
à utiliser la variable d'environnement PERL5LIB pour continuer à
utiliser les binaires existants mais en leur permettant d'aller
chercher des modules ailleurs que dans les répertoires prédéfinis. Ça
devrait fonctionner puisque il n'est manifestement pas question de
modifier les exécutables.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 10 Dec 2008 17:26:09 +0100, Nabot Leon écrivait (wrote):
Paul Gaborit a écrit :
La solution propre pour éviter ces bidouilles passe par une recompilation... Ce qui n'est sans doute pas à la portée de l'utilisateur évoqué ci-dessus. Par contre, c'est faisable à partir d'une autre machine (facilement si c'est le même système ou sinon via une cross-compilation).
Notez, qu'il n'est pas possible d'utiliser un lien symbolique pour re-diriger l'ancien chemin vers la nouvelle localisation.
Et si le lien se fait dans l'autre sens : la nouvelle localisation est un lien vers l'ancienne ?
Non, pas possible, l'ancienne installation restant en place.
Les vraies "bonnes" questions sont : quel unix utilisez-vous et pourquoi avez-vous besoin de déplacer le perl existant ?
Solaris. La raison en fait était de créer un duplicata d'une installation Perl existante dans un autre emplacement afin de pouvoir la bidouiller pour y ajouter certains modules exotiques. L'ancienne version utilisée par un serveur en production devant rester inchangée.
Quand à recompiler, je préfère éviter car il faudrait aussi que je re-installe toutes les librairies qui ont servi à créer les divers modules et qui étaient statiques. Et comme de bien entendu, ces librairies ont été supprimées depuis.
Ok pour le contexte qui n'est effectivement pas simple (voire risquée puisqu'il ne semble pas y avoir de serveur de test).
Une solution serait de passer par un 'chroot' ou par le truc équivalent aux jails de BSD mais pour Solaris (ça s'appel les "zones" dans OpenSolaris mais je ne me souviens plus du nom que ça portait avant). Ça permet de copier l'installation perl existante ailleurs et de lui faire croire qu'elle est toujours au même endroit.
Une autre solution (très bidouillesque et risquée) : copier les exécutables et autres bibliothèques perl et éditer à la main les chemins hardcodés (en supposant qu'ils ont la même longueur que les chemins originaux).
Reste quand même la solution que j'évoquais initialement qui consiste à utiliser la variable d'environnement PERL5LIB pour continuer à utiliser les binaires existants mais en leur permettant d'aller chercher des modules ailleurs que dans les répertoires prédéfinis. Ça devrait fonctionner puisque il n'est manifestement pas question de modifier les exécutables.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nabot Leon
Paul Gaborit a écrit :
Ok pour le contexte qui n'est effectivement pas simple (voire risquée puisqu'il ne semble pas y avoir de serveur de test).
Une solution serait de passer par un 'chroot' ou par le truc équivalent aux jails de BSD mais pour Solaris (ça s'appel les "zone s" dans OpenSolaris mais je ne me souviens plus du nom que ça portait avant). Ça permet de copier l'installation perl existante ailleurs et de lui faire croire qu'elle est toujours au même endroit.
Une autre solution (très bidouillesque et risquée) : copier les exécutables et autres bibliothèques perl et éditer à la main le s chemins hardcodés (en supposant qu'ils ont la même longueur que les chemins originaux).
Reste quand même la solution que j'évoquais initialement qui consis te à utiliser la variable d'environnement PERL5LIB pour continuer à utiliser les binaires existants mais en leur permettant d'aller chercher des modules ailleurs que dans les répertoires prédéfinis . Ça devrait fonctionner puisque il n'est manifestement pas question de modifier les exécutables.
J'ai finit par choisir la solution la plus simple, bien que pas très pr opre, lui installer le Perl actuel sur sa machine perso avec le même chemin e t y rajouter les modules complémentaires. Il devra se contenter de faire to urner ses outils depuis sa machine perso.
Au moins quoi qu'il arrive, s'il y a un pépin avec ce Perl tuné il se ra le seul à en souffrir.
En tout cas, merci pour les suggestions que je garderai dans un coin si j amais j'avais à résoudre à nouveau ce genre de problème.
Cdlt
Léo
Paul Gaborit a écrit :
Ok pour le contexte qui n'est effectivement pas simple (voire risquée
puisqu'il ne semble pas y avoir de serveur de test).
Une solution serait de passer par un 'chroot' ou par le truc
équivalent aux jails de BSD mais pour Solaris (ça s'appel les "zone s"
dans OpenSolaris mais je ne me souviens plus du nom que ça portait
avant). Ça permet de copier l'installation perl existante ailleurs et
de lui faire croire qu'elle est toujours au même endroit.
Une autre solution (très bidouillesque et risquée) : copier les
exécutables et autres bibliothèques perl et éditer à la main le s
chemins hardcodés (en supposant qu'ils ont la même longueur que les
chemins originaux).
Reste quand même la solution que j'évoquais initialement qui consis te
à utiliser la variable d'environnement PERL5LIB pour continuer à
utiliser les binaires existants mais en leur permettant d'aller
chercher des modules ailleurs que dans les répertoires prédéfinis . Ça
devrait fonctionner puisque il n'est manifestement pas question de
modifier les exécutables.
J'ai finit par choisir la solution la plus simple, bien que pas très pr opre,
lui installer le Perl actuel sur sa machine perso avec le même chemin e t y
rajouter les modules complémentaires. Il devra se contenter de faire to urner
ses outils depuis sa machine perso.
Au moins quoi qu'il arrive, s'il y a un pépin avec ce Perl tuné il se ra le
seul à en souffrir.
En tout cas, merci pour les suggestions que je garderai dans un coin si j amais
j'avais à résoudre à nouveau ce genre de problème.
Ok pour le contexte qui n'est effectivement pas simple (voire risquée puisqu'il ne semble pas y avoir de serveur de test).
Une solution serait de passer par un 'chroot' ou par le truc équivalent aux jails de BSD mais pour Solaris (ça s'appel les "zone s" dans OpenSolaris mais je ne me souviens plus du nom que ça portait avant). Ça permet de copier l'installation perl existante ailleurs et de lui faire croire qu'elle est toujours au même endroit.
Une autre solution (très bidouillesque et risquée) : copier les exécutables et autres bibliothèques perl et éditer à la main le s chemins hardcodés (en supposant qu'ils ont la même longueur que les chemins originaux).
Reste quand même la solution que j'évoquais initialement qui consis te à utiliser la variable d'environnement PERL5LIB pour continuer à utiliser les binaires existants mais en leur permettant d'aller chercher des modules ailleurs que dans les répertoires prédéfinis . Ça devrait fonctionner puisque il n'est manifestement pas question de modifier les exécutables.
J'ai finit par choisir la solution la plus simple, bien que pas très pr opre, lui installer le Perl actuel sur sa machine perso avec le même chemin e t y rajouter les modules complémentaires. Il devra se contenter de faire to urner ses outils depuis sa machine perso.
Au moins quoi qu'il arrive, s'il y a un pépin avec ce Perl tuné il se ra le seul à en souffrir.
En tout cas, merci pour les suggestions que je garderai dans un coin si j amais j'avais à résoudre à nouveau ce genre de problème.
Cdlt
Léo
Paul Gaborit
À (at) Fri, 12 Dec 2008 16:24:07 +0100, Nabot Leon écrivait (wrote):
J'ai finit par choisir la solution la plus simple, bien que pas très propre, lui installer le Perl actuel sur sa machine perso avec le même chemin et y rajouter les modules complémentaires. Il devra se contenter de faire tourner ses outils depuis sa machine perso.
Au moins quoi qu'il arrive, s'il y a un pépin avec ce Perl tuné il sera le seul à en souffrir.
Cela semble correspondre à ma définition d'une machine de test. Et donc ce n'est pas une solution que je qualifierai de "pas très propre". Au contraire, même. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 12 Dec 2008 16:24:07 +0100,
Nabot Leon <nabotleon@N0SpamZ.hotmail.com> écrivait (wrote):
J'ai finit par choisir la solution la plus simple, bien que pas très
propre, lui installer le Perl actuel sur sa machine perso avec le même
chemin et y rajouter les modules complémentaires. Il devra se
contenter de faire tourner ses outils depuis sa machine perso.
Au moins quoi qu'il arrive, s'il y a un pépin avec ce Perl tuné il
sera le seul à en souffrir.
Cela semble correspondre à ma définition d'une machine de test. Et
donc ce n'est pas une solution que je qualifierai de "pas très
propre". Au contraire, même. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 12 Dec 2008 16:24:07 +0100, Nabot Leon écrivait (wrote):
J'ai finit par choisir la solution la plus simple, bien que pas très propre, lui installer le Perl actuel sur sa machine perso avec le même chemin et y rajouter les modules complémentaires. Il devra se contenter de faire tourner ses outils depuis sa machine perso.
Au moins quoi qu'il arrive, s'il y a un pépin avec ce Perl tuné il sera le seul à en souffrir.
Cela semble correspondre à ma définition d'une machine de test. Et donc ce n'est pas une solution que je qualifierai de "pas très propre". Au contraire, même. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
