Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3)
Comme son site de production n'autorise pas le build, le module est
constitué à domicile avec les commandes traditionelles.
perl Makefile.PL
make etc.
Une fois achevé, quelle est la procédure pour ne livrer au client *que* la
partie qui l'intéresse, à savoir ce qui sera installé dans perlxx/site/lib ?
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3) Comme son site de production n'autorise pas le build, le module est constitué à domicile avec les commandes traditionelles. perl Makefile.PL make etc. Une fois achevé, quelle est la procédure pour ne livrer au client *que* la partie qui l'intéresse, à savoir ce qui sera installé dans perlxx/site/lib ?
Archive::Tar est un package purement Perl donc il suffit de recopier les 3 fichiers .pm qui sont dedans.
Mais il dépend d'autres modules comme IO::Zlib, Compress::Zlib ou IO::Compress::Gzip qui, eux, contiennent du code en C compilés sous la forme de bibliothèques dynamiques (.so, .bs ou autres). C'est tout cela qu'il faut copier et fournir. Déjà, il faudrait être sûr que vous utilisez une version de AIX suffisament proche de celle de votre client pour ne pas avoir de problème avec ces bibliothèques dynamiques que vous aurez compilées vous-même. Ensuite, il faut trouver toutes les dépendances (tous les modules dont Archive::Tar dépend) et les fournir aussi. Et finalement, il y a une petite chance que ça marche... Une fois installé, tous ces fichiers sont quelque part dans les sous-répertoires des répertoires de @INC.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3)
Comme son site de production n'autorise pas le build, le module est
constitué à domicile avec les commandes traditionelles.
perl Makefile.PL
make etc.
Une fois achevé, quelle est la procédure pour ne livrer au client *que* la
partie qui l'intéresse, à savoir ce qui sera installé dans perlxx/site/lib ?
Archive::Tar est un package purement Perl donc il suffit de recopier
les 3 fichiers .pm qui sont dedans.
Mais il dépend d'autres modules comme IO::Zlib, Compress::Zlib ou
IO::Compress::Gzip qui, eux, contiennent du code en C compilés sous la
forme de bibliothèques dynamiques (.so, .bs ou autres). C'est tout
cela qu'il faut copier et fournir. Déjà, il faudrait être sûr que vous
utilisez une version de AIX suffisament proche de celle de votre
client pour ne pas avoir de problème avec ces bibliothèques dynamiques
que vous aurez compilées vous-même. Ensuite, il faut trouver toutes
les dépendances (tous les modules dont Archive::Tar dépend) et les
fournir aussi. Et finalement, il y a une petite chance que ça
marche... Une fois installé, tous ces fichiers sont quelque part dans
les sous-répertoires des répertoires de @INC.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3) Comme son site de production n'autorise pas le build, le module est constitué à domicile avec les commandes traditionelles. perl Makefile.PL make etc. Une fois achevé, quelle est la procédure pour ne livrer au client *que* la partie qui l'intéresse, à savoir ce qui sera installé dans perlxx/site/lib ?
Archive::Tar est un package purement Perl donc il suffit de recopier les 3 fichiers .pm qui sont dedans.
Mais il dépend d'autres modules comme IO::Zlib, Compress::Zlib ou IO::Compress::Gzip qui, eux, contiennent du code en C compilés sous la forme de bibliothèques dynamiques (.so, .bs ou autres). C'est tout cela qu'il faut copier et fournir. Déjà, il faudrait être sûr que vous utilisez une version de AIX suffisament proche de celle de votre client pour ne pas avoir de problème avec ces bibliothèques dynamiques que vous aurez compilées vous-même. Ensuite, il faut trouver toutes les dépendances (tous les modules dont Archive::Tar dépend) et les fournir aussi. Et finalement, il y a une petite chance que ça marche... Une fois installé, tous ces fichiers sont quelque part dans les sous-répertoires des répertoires de @INC.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
espie
In article <49d4d5ee$0$16639$, JCG wrote:
Bonjour,
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3) Comme son site de production n'autorise pas le build, le module est constitué à domicile avec les commandes traditionelles.
Trouve un client moins con ?
(desole pour le troll, parfois ca soulage).
A priori, il doit avoir un environnement de test *identique* a l'environnement de production. Donc tu buildes sur l'environnement de test, tu fais un diff avant et apres, et tu copies ce qui a change.
De mon point de vue, la seule raison valable pour eviter les builds sur un environnement de prod, c'est pour etre sur que ca soit reproductible... donc si tu buildes chez toi et lui donne les fichiers sans lui expliquer, ca ne va pas l'arranger. Ca sent la regle debile 'pas de build sur les machines en prod' dont l'esprit est regulierement contourne parce que les gens qui implementent n'ont pas compris pourquoi...
In article <49d4d5ee$0$16639$426a74cc@news.free.fr>,
JCG <jeancharles__and__g@free.fr.invalid> wrote:
Bonjour,
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3)
Comme son site de production n'autorise pas le build, le module est
constitué à domicile avec les commandes traditionelles.
Trouve un client moins con ?
(desole pour le troll, parfois ca soulage).
A priori, il doit avoir un environnement de test *identique* a l'environnement
de production. Donc tu buildes sur l'environnement de test, tu fais un diff
avant et apres, et tu copies ce qui a change.
De mon point de vue, la seule raison valable pour eviter les builds sur un
environnement de prod, c'est pour etre sur que ca soit reproductible...
donc si tu buildes chez toi et lui donne les fichiers sans lui expliquer,
ca ne va pas l'arranger. Ca sent la regle debile 'pas de build sur les
machines en prod' dont l'esprit est regulierement contourne parce que les
gens qui implementent n'ont pas compris pourquoi...
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3) Comme son site de production n'autorise pas le build, le module est constitué à domicile avec les commandes traditionelles.
Trouve un client moins con ?
(desole pour le troll, parfois ca soulage).
A priori, il doit avoir un environnement de test *identique* a l'environnement de production. Donc tu buildes sur l'environnement de test, tu fais un diff avant et apres, et tu copies ce qui a change.
De mon point de vue, la seule raison valable pour eviter les builds sur un environnement de prod, c'est pour etre sur que ca soit reproductible... donc si tu buildes chez toi et lui donne les fichiers sans lui expliquer, ca ne va pas l'arranger. Ca sent la regle debile 'pas de build sur les machines en prod' dont l'esprit est regulierement contourne parce que les gens qui implementent n'ont pas compris pourquoi...
JCG
"Marc Espie" a écrit dans le message de news: gr3cqs$c1t$
In article <49d4d5ee$0$16639$, JCG wrote:
Bonjour,
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3) Comme son site de production n'autorise pas le build, le module est constitué à domicile avec les commandes traditionelles.
Trouve un client moins con ?
(desole pour le troll, parfois ca soulage).
A priori, il doit avoir un environnement de test *identique* a l'environnement de production. Donc tu buildes sur l'environnement de test, tu fais un diff avant et apres, et tu copies ce qui a change.
De mon point de vue, la seule raison valable pour eviter les builds sur un environnement de prod, c'est pour etre sur que ca soit reproductible... donc si tu buildes chez toi et lui donne les fichiers sans lui expliquer, ca ne va pas l'arranger. Ca sent la regle debile 'pas de build sur les machines en prod' dont l'esprit est regulierement contourne parce que les gens qui implementent n'ont pas compris pourquoi...
Merci a Paul et à toi. Je ne citerai donc par le nom du client par compassion :-) (Une grosse entreprise bien connue, mais bon, ces décisions *débiles* sont plus dues a la prestation qu'au client). Donc oui, je dois embarquer le binaire correspondant aux différentes compressions en fonction dans le programme et j'espérais secrètement que dans le module CPAN la partie "produit" se détachait naturellement de la partie "développement" permettant au build de générer un répertoire pret à l'emploi. Ainsi il ne nécéssiterai plus qu' une commande du genre "make install", apt-get ou ppm -install en guise de déploiement. Pour le coup du "diff", c'est généralement ce que nous faisons pour tout les modules que nous embarquons mais c'est assez pénible car il faut prévoir une installation en environnement vierge. En définitive on va certainement en passer par là, le *prestataire du client* est roi :-/
"Marc Espie" <espie@lain.home> a écrit dans le message de news:
gr3cqs$c1t$1@biggoron.nerim.net...
In article <49d4d5ee$0$16639$426a74cc@news.free.fr>,
JCG <jeancharles__and__g@free.fr.invalid> wrote:
Bonjour,
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX
(5.3)
Comme son site de production n'autorise pas le build, le module est
constitué à domicile avec les commandes traditionelles.
Trouve un client moins con ?
(desole pour le troll, parfois ca soulage).
A priori, il doit avoir un environnement de test *identique* a
l'environnement
de production. Donc tu buildes sur l'environnement de test, tu fais un
diff
avant et apres, et tu copies ce qui a change.
De mon point de vue, la seule raison valable pour eviter les builds sur un
environnement de prod, c'est pour etre sur que ca soit reproductible...
donc si tu buildes chez toi et lui donne les fichiers sans lui expliquer,
ca ne va pas l'arranger. Ca sent la regle debile 'pas de build sur les
machines en prod' dont l'esprit est regulierement contourne parce que les
gens qui implementent n'ont pas compris pourquoi...
Merci a Paul et à toi.
Je ne citerai donc par le nom du client par compassion :-)
(Une grosse entreprise bien connue, mais bon, ces décisions *débiles* sont
plus dues a la prestation qu'au client).
Donc oui, je dois embarquer le binaire correspondant aux différentes
compressions en fonction dans le programme et j'espérais secrètement que
dans le module CPAN la partie "produit" se détachait naturellement de la
partie "développement" permettant au build de générer un répertoire pret à
l'emploi.
Ainsi il ne nécéssiterai plus qu' une commande du genre "make install",
apt-get ou ppm -install en guise de déploiement.
Pour le coup du "diff", c'est généralement ce que nous faisons pour tout les
modules que nous embarquons mais c'est assez pénible car il faut prévoir une
installation en environnement vierge.
En définitive on va certainement en passer par là, le *prestataire du
client* est roi :-/
"Marc Espie" a écrit dans le message de news: gr3cqs$c1t$
In article <49d4d5ee$0$16639$, JCG wrote:
Bonjour,
Je souhaiterais livrer le module Archive::Tar 1.4x à un client sur AIX (5.3) Comme son site de production n'autorise pas le build, le module est constitué à domicile avec les commandes traditionelles.
Trouve un client moins con ?
(desole pour le troll, parfois ca soulage).
A priori, il doit avoir un environnement de test *identique* a l'environnement de production. Donc tu buildes sur l'environnement de test, tu fais un diff avant et apres, et tu copies ce qui a change.
De mon point de vue, la seule raison valable pour eviter les builds sur un environnement de prod, c'est pour etre sur que ca soit reproductible... donc si tu buildes chez toi et lui donne les fichiers sans lui expliquer, ca ne va pas l'arranger. Ca sent la regle debile 'pas de build sur les machines en prod' dont l'esprit est regulierement contourne parce que les gens qui implementent n'ont pas compris pourquoi...
Merci a Paul et à toi. Je ne citerai donc par le nom du client par compassion :-) (Une grosse entreprise bien connue, mais bon, ces décisions *débiles* sont plus dues a la prestation qu'au client). Donc oui, je dois embarquer le binaire correspondant aux différentes compressions en fonction dans le programme et j'espérais secrètement que dans le module CPAN la partie "produit" se détachait naturellement de la partie "développement" permettant au build de générer un répertoire pret à l'emploi. Ainsi il ne nécéssiterai plus qu' une commande du genre "make install", apt-get ou ppm -install en guise de déploiement. Pour le coup du "diff", c'est généralement ce que nous faisons pour tout les modules que nous embarquons mais c'est assez pénible car il faut prévoir une installation en environnement vierge. En définitive on va certainement en passer par là, le *prestataire du client* est roi :-/
espie
In article <49d5d4ce$0$23750$, JCG wrote:
Merci a Paul et à toi. Je ne citerai donc par le nom du client par compassion :-) (Une grosse entreprise bien connue, mais bon, ces décisions *débiles* sont plus dues a la prestation qu'au client). Donc oui, je dois embarquer le binaire correspondant aux différentes compressions en fonction dans le programme et j'espérais secrètement que dans le module CPAN la partie "produit" se détachait naturellement de la partie "développement" permettant au build de générer un répertoire pret à l'emploi. Ainsi il ne nécéssiterai plus qu' une commande du genre "make install", apt-get ou ppm -install en guise de déploiement. Pour le coup du "diff", c'est généralement ce que nous faisons pour tout les modules que nous embarquons mais c'est assez pénible car il faut prévoir une installation en environnement vierge. En définitive on va certainement en passer par là, le *prestataire du client* est roi :-/
A part ca, tu peux peut-etre adapter ce qu'on fait dans OpenBSD. On fabrique des packages binaires a partir des builds, et on installe les packages ensuite...
Ca veut dire qu'on sait installer des trucs "ailleurs" qu'a leur emplacement definitif.
Ca veut juste dire qu'on a une config de perl adaptee.
Pour te faire une idee, on a quelque chose genre: /usr/bin/perl Makefile.PL PREFIX='${PREFIX}' INSTALLSITELIB='${PREFIX}/libdata/perl5/site_perl' INSTALLSITEARCH="$${INSTALLSITELIB}/$$arch" INSTALLPRIVLIB='/usr/./libdata/perl5' INSTALLARCHLIB="$${INSTALLPRIVLIB}/$$arch" INSTALLMAN1DIR='${PREFIX}/man/man1' INSTALLMAN3DIR='${PREFIX}/man/man3p' INSTALLBIN='$${PREFIX}/bin' INSTALLSCRIPT='$${INSTALLBIN}' ${CONFIGURE_ARGS}
dans notre Makefile de build. Note les $${PREFIX} et $${INSTALLBIN}, c'est tres important.
Ca veut dire que le Makefile genere par Makefile.PL *contient* ${PREFIX} et ${INSTALLBIN}, non etendu.
Si tu connais un peu ton make, tu dois savoir que si tu ecris make VAR=value eh bien, c'est la valeur de VAR passee en ligne de commande qui prend le pas sur le contenu du makefile.
Le make se fait donc de maniere standard avec les valeurs classiques de tous ces repertoires. C'est juste pour le "make install" qu'on fait un tour de passe-passe, en passant des valeurs appropriees de toutes ces variables pour que l'installation depose tout dans un repertoire specifique (on appelle ca fake, fausse installation chez nous). Et ensuite, on n'a plus qu'a packager l'ensemble...
(on a un truc tres similaire pour les modbuild).
confere le cvsweb d'open si tu as besoin de details. C'est dans notre infrastructure de ports, dans ports/infrastructure/mk/perl.port.mk
C'est evidemment egalement un peu specifique aux hints d'install perl d'OpenBSD... on separe les trucs du systeme dans /usr et les modules divers (CPAN et autres) dans /usr/local...
In article <49d5d4ce$0$23750$426a74cc@news.free.fr>,
JCG <jeancharles__and__g@free.fr.invalid> wrote:
Merci a Paul et à toi.
Je ne citerai donc par le nom du client par compassion :-)
(Une grosse entreprise bien connue, mais bon, ces décisions *débiles* sont
plus dues a la prestation qu'au client).
Donc oui, je dois embarquer le binaire correspondant aux différentes
compressions en fonction dans le programme et j'espérais secrètement que
dans le module CPAN la partie "produit" se détachait naturellement de la
partie "développement" permettant au build de générer un répertoire pret à
l'emploi.
Ainsi il ne nécéssiterai plus qu' une commande du genre "make install",
apt-get ou ppm -install en guise de déploiement.
Pour le coup du "diff", c'est généralement ce que nous faisons pour tout les
modules que nous embarquons mais c'est assez pénible car il faut prévoir une
installation en environnement vierge.
En définitive on va certainement en passer par là, le *prestataire du
client* est roi :-/
A part ca, tu peux peut-etre adapter ce qu'on fait dans OpenBSD.
On fabrique des packages binaires a partir des builds, et on installe
les packages ensuite...
Ca veut dire qu'on sait installer des trucs "ailleurs" qu'a leur emplacement
definitif.
Ca veut juste dire qu'on a une config de perl adaptee.
Pour te faire une idee, on a quelque chose genre:
/usr/bin/perl Makefile.PL
PREFIX='${PREFIX}'
INSTALLSITELIB='${PREFIX}/libdata/perl5/site_perl'
INSTALLSITEARCH="$${INSTALLSITELIB}/$$arch"
INSTALLPRIVLIB='/usr/./libdata/perl5'
INSTALLARCHLIB="$${INSTALLPRIVLIB}/$$arch"
INSTALLMAN1DIR='${PREFIX}/man/man1'
INSTALLMAN3DIR='${PREFIX}/man/man3p'
INSTALLBIN='$${PREFIX}/bin'
INSTALLSCRIPT='$${INSTALLBIN}' ${CONFIGURE_ARGS}
dans notre Makefile de build.
Note les $${PREFIX} et $${INSTALLBIN}, c'est tres important.
Ca veut dire que le Makefile genere par Makefile.PL *contient* ${PREFIX}
et ${INSTALLBIN}, non etendu.
Si tu connais un peu ton make, tu dois savoir que si tu ecris
make VAR=value
eh bien, c'est la valeur de VAR passee en ligne de commande qui prend
le pas sur le contenu du makefile.
Le make se fait donc de maniere standard avec les valeurs classiques de
tous ces repertoires. C'est juste pour le "make install" qu'on fait
un tour de passe-passe, en passant des valeurs appropriees de toutes ces
variables pour que l'installation depose tout dans un repertoire specifique
(on appelle ca fake, fausse installation chez nous). Et ensuite, on n'a
plus qu'a packager l'ensemble...
(on a un truc tres similaire pour les modbuild).
confere le cvsweb d'open si tu as besoin de details. C'est dans notre
infrastructure de ports, dans ports/infrastructure/mk/perl.port.mk
C'est evidemment egalement un peu specifique aux hints d'install perl
d'OpenBSD... on separe les trucs du systeme dans /usr et les modules divers
(CPAN et autres) dans /usr/local...
Merci a Paul et à toi. Je ne citerai donc par le nom du client par compassion :-) (Une grosse entreprise bien connue, mais bon, ces décisions *débiles* sont plus dues a la prestation qu'au client). Donc oui, je dois embarquer le binaire correspondant aux différentes compressions en fonction dans le programme et j'espérais secrètement que dans le module CPAN la partie "produit" se détachait naturellement de la partie "développement" permettant au build de générer un répertoire pret à l'emploi. Ainsi il ne nécéssiterai plus qu' une commande du genre "make install", apt-get ou ppm -install en guise de déploiement. Pour le coup du "diff", c'est généralement ce que nous faisons pour tout les modules que nous embarquons mais c'est assez pénible car il faut prévoir une installation en environnement vierge. En définitive on va certainement en passer par là, le *prestataire du client* est roi :-/
A part ca, tu peux peut-etre adapter ce qu'on fait dans OpenBSD. On fabrique des packages binaires a partir des builds, et on installe les packages ensuite...
Ca veut dire qu'on sait installer des trucs "ailleurs" qu'a leur emplacement definitif.
Ca veut juste dire qu'on a une config de perl adaptee.
Pour te faire une idee, on a quelque chose genre: /usr/bin/perl Makefile.PL PREFIX='${PREFIX}' INSTALLSITELIB='${PREFIX}/libdata/perl5/site_perl' INSTALLSITEARCH="$${INSTALLSITELIB}/$$arch" INSTALLPRIVLIB='/usr/./libdata/perl5' INSTALLARCHLIB="$${INSTALLPRIVLIB}/$$arch" INSTALLMAN1DIR='${PREFIX}/man/man1' INSTALLMAN3DIR='${PREFIX}/man/man3p' INSTALLBIN='$${PREFIX}/bin' INSTALLSCRIPT='$${INSTALLBIN}' ${CONFIGURE_ARGS}
dans notre Makefile de build. Note les $${PREFIX} et $${INSTALLBIN}, c'est tres important.
Ca veut dire que le Makefile genere par Makefile.PL *contient* ${PREFIX} et ${INSTALLBIN}, non etendu.
Si tu connais un peu ton make, tu dois savoir que si tu ecris make VAR=value eh bien, c'est la valeur de VAR passee en ligne de commande qui prend le pas sur le contenu du makefile.
Le make se fait donc de maniere standard avec les valeurs classiques de tous ces repertoires. C'est juste pour le "make install" qu'on fait un tour de passe-passe, en passant des valeurs appropriees de toutes ces variables pour que l'installation depose tout dans un repertoire specifique (on appelle ca fake, fausse installation chez nous). Et ensuite, on n'a plus qu'a packager l'ensemble...
(on a un truc tres similaire pour les modbuild).
confere le cvsweb d'open si tu as besoin de details. C'est dans notre infrastructure de ports, dans ports/infrastructure/mk/perl.port.mk
C'est evidemment egalement un peu specifique aux hints d'install perl d'OpenBSD... on separe les trucs du systeme dans /usr et les modules divers (CPAN et autres) dans /usr/local...
