7
votes

Comment puis-je dire quels modules ont été fournis à l'origine de l'installation de Perl spécifique sur une machine?

Comment puis-je dire quels modules ont été fournis à l'origine de l'installation Perl spécifique sur une machine?

(c'est pas un duplicata de: Comment puis-je dire si un module PERL est noyau ou une partie de l'installation standard? ("Comment puis-je dire si un module Perl est noyau ou une partie de l'installation standard?") - C'est en fait une question de retournement)

Je cherche ce qui est venu avec l'installation à l'origine , quels modules ont été fournis dans le cadre de cette installation, ce qui a été intégré. Pas ce qui a été installé depuis.

J'aimerais que cela fonctionne avec toute version perl.

Je veux pouvoir faire ceci:

Utilisation d'un script dans un programme Perl lui-même / commande sur la machine qui a l'installation. Donc, pour cela, je vous appuierais à l'installation pour avoir un enregistrement sous une forme sur ce qu'il a à l'origine.
sur le package téléchargé avant de faire l'installation. Demandez-lui quels modules il a.
Les raisons pour lesquelles je veux faire ceci est:

Je veux savoir quels modules je peux attendre par défaut lorsque vous écrivez un logiciel pour exécuter sur une machine avec l'installation PERL et quels modules dont je devrais ajouter qui ne sont pas par défaut
Si je garde l'image d'installation d'origine / package ou savoir comment obtenir la chose exacte à nouveau en ligne, j'ai une installation de Perl cohérente répétable pour plusieurs machines avec la connaissance de quels modules seront présents et quels modules ne seront pas. < / li>
Mon logiciel PERL aura une procédure de déploiement bien définie, car il est facile de définir exactement ce qui est requis par le logiciel
Je ne pourra peut-être pas simplement mettre à jour / mettre à niveau la version Perl facilement en raison des politiques en place dans mon organisation (c'est comme ça que c'est, je ne veux pas de discussion latérale à ce sujet). Cette politique peut être justifiée car il y a toujours une mise à niveau des risques vers de nouveaux logiciels pouvant dépasser les avantages. Les développeurs doivent donc savoir ce qu'ils peuvent s'attendre à être disponible.
La raison pour laquelle je pose cette question est parce que, pour toute version PERL, il semble de ne pas être un moyen automatisé de déterminer l'installation globale de la norme définissant quels modules vous pouvez vous attendre à être présents dans votre installation par défaut sur votre ordinateur - Voir la question: Comment puis-je dire si un module PERL est noyau ou une partie de l'installation standard? ("Comment puis-je dire si un module PERL est noyau ou une partie de l'installation standard?")
Les versions PERL ne peuvent pas être invoquées à vous dire quels modules sont présents ou non. Bien sûr, il pourrait y avoir une documentation en ligne qui vous dit. Mais j'ai besoin d'une façon automatisée de faire cela sur la libération que je télécharge / installation. Même la même version Perl sur différentes distributions Linux / Unix peut être différente.

deployment perl perl-module

7 commentaires

Avez-vous pensé à utiliser par ou maritime?

Vous avez déjà la réponse à cette question très générale. Une meilleure question, qui a une réponse, serait quelque chose comme "Comment savoir quels modules Perl Debian est venu?"

@brian D FOY: Oui Debian Certainement, mais je dois être capable de le faire sur diverses autres distributions également, comme indiqué sur la question de savoir que cela a été renvoyé de ( Stackoverflow.com/questions/2049735 )

@ALEXANDR CIORNII: Merci, je vais regarder dans le nivelier, j'ai trouvé jusqu'à présent: search.cpan.org/~sunnavy/iverwright-2.4.4 et pour le pair, j'ai trouvé: Par.Perl.org/wiki/Main_Page

@ROB: Oui, je me rends compte que vous voulez cela pour différentes plates-formes, mais chaque plate-forme (et chaque version de cette plate-forme) va avoir une réponse différente. Vous n'allez pas obtenir de meilleures réponses que vous n'avez déjà que si vous affiez votre question.

@brian D FOY. "Chaque plate-forme (et chaque version de cette plate-forme) va avoir une réponse différente" +1 pour la vérification de la réalité. Mais cette vérité est très très malheureuse: quel dîner de désordre déployant Perl est alors! Définitivement un inconvénient d'utiliser Perl parmi ses nombreux bons points. Quel est le point d'avoir des numéros de libération du tout? 5.8, 5.9, etc. et comment ils sont confus qu'ils apparaissent au point 5.008.001 pour 5.8, par exemple, etc. dans certaines situations. Je vais regarder les approches alternatives de @Michael Carman et @ Gbacon. Encore une fois, merci à tout le monde pour l'entrée.

@Rob: La situation que vous décrivez n'a rien à voir avec quoi que ce soit de Perl. Et le vendeur peut faire presque n'importe quoi à tout ce qu'ils distribuent, qu'il s'agisse d'un langage de programmation, de polices ou d'autre chose. Perl fournit une très belle norme qui fonctionnerait assez bien si les vendeurs l'utilisaient. Ils le changent, et c'est le dîner du chien que le vendeur vous donne. Je ne pense pas que vous obtenez cela peu importe combien de fois nous le disons: ce sont les vendeurs qui reconquitent des choses qui rendent votre vie difficile.

3 Réponses :

0
votes

je cherche ce qui est venu avec le Installation à l'origine, quels modules ont été fournis dans le cadre de cette Installation, ce qui a été intégré. NE PAS Ce qui a été installé depuis.
Peut-être pour les modules non corporels que vous pouvez analyser Perllocal.pod, séparer le lot initial de modules installé avec l'installation Perl elle-même à partir de la part de la date de la date. Vous recherchez des lignes telles que: xxx
afin que les premiers ne soient probablement ceux qui ont été installés avec Perl lui-même et doivent avoir la même date (bien que non au même moment. bien sûr). Ceux installés à une différence de 24 heures ou plus seraient ce que vous recherchez.
Je ne sais pas sur les modules de base, comme à mon avis, les réponses que vous avez obtenues dans la question précédente que vous avez liée est satisfaisante, mais Clairement, vous ne l'avez pas pensé. Il me manque probablement quelque chose :)
acclamations, Offre

3 commentaires

Perllocal.Pod est toujours obligé d'échouer. Cela ne fonctionne que pour ces outils qui s'occupent de la mettre à jour, et pas du tout pour les goody the utilisateurs font à la main.

@ Solid-State: «Pas sûr des modules de base, comme à mon avis, les réponses que vous avez obtenues dans la question précédente que vous avez liée est satisfaisante" - je suis d'accord sur les réponses dans sont bons (merciangs) mais les solutions ne gèrent que des versions relativement très récentes de Perl que je pense que je devrai accepter - cela plus à faire avec la voie de la voie est plutôt que la capacité des affiches de réponse! @Michael Carman prend également ce point de vue ci-dessus dans le cadre de sa réponse.

@ROB: Les solutions traitent de la plupart des Perls libérés au cours des 15 dernières années. Ce n'est pas un porblem avec Perl. Vous continuez à manquer le fait que ceci est un problème de replanchers, que personne ne peut empêcher de briser et de faire baller de quoi ils distribuent.

6
votes

Pour Debian ou Ubuntu, vous pouvez utiliser
$ rpm -ql perl | grep '\.pm$'

5 commentaires

Sur OpenSUSE: > RPM -QL Perl Perl-Doc | Grep '\ .PM $'
Celles-ci vous montrent les fichiers que vous avez maintenant, pas pour une installation vierge, n'est-ce pas? @gbacon merci. Je vais jeter un coup d'œil sur ce que cela va et reviendrai un peu plus tard pour voir s'il y a des commentaires sur la question de @brian D Foy et plus de pensées. @brian: Non. Je ne peux pas parler de Redhat, mais dans Debian dpkg -l | --Listfiles Package Affiche les fichiers associés à seulement ce paquet spécifique. Et à Debian, si vous installez d'autres modules, ils viennent d'autres packages. Donc, dpkg -l perl ne montrera que les fichiers de l'installation de base perl. +1 Pour votre réponse @gbacon, j'espère que la liste résultante est destinée à une "installation vierge".
6 votes En général, vous ne pouvez pas. Vous aurez beaucoup moins de frustration si vous acceptez cela et approchez-vous du problème d'un angle différent. Module :: Corelist fournit une liste de ce que devrait être être Inclus dans toutes les installations comme un minimum minimum mais les fournisseurs ne sont pas tenus de respecter cela et la plupart des distributions incluent de nombreux modules qui ne font pas partie du noyau. En empêchant la construction de votre propre base de données de ce qui a été inclus dans quelle version de chaque distribution - une tâche intimidante - il n'y a pas beaucoup d'espoir. Notez que même pour les modules fournis avec une distribution, la version installée peut être différente. Je peux voir quelques façons différentes d'aborder ceci: Si vous connaissez votre cible au moment du développement (par exemple un spécifique Version d'ActivePerl) Vous pouvez prendre des décisions en fonction de cela. Pour l'affaire Général Déployez votre application comme un module et spécifiez dépendances. par exemple. Utilisez Module :: Construire et liste des prérequis dans le nécessite une section du script build.pl. Le CPAN Shell peut suivre et résoudre dépendances automatiquement. Si vous voulez éviter le problème, utilisez entièrement par et Par :: Packer à créer des paquets de déploiement autonomes. 2 commentaires Merci +1 - ça a l'air bien. Je vais examiner un peu plus quand plus de temps et suivi avec plus de pensées / décision. J'ai accepté cette réponse car elle donne la plus grande portée d'une réponse, encourage-moi à réfléchir au problème. Crédit et +1 à @gbacon aussi.

Articles qui pourrait vous intéresser : Échec de l'exécution de l'objectif org.maven.plugins: maven-compiler-plugin: 3.8.1: compile (default-compile) sur le projet (cible 11) erreur: ce n'est probablement pas un problème avec npm. Il y a probablement une sortie de journalisation supplémentaire ci-dessus ssh_init: Erreur réseau: impossible d'attribuer l'adresse demandée Impossible de trouver le fichier lors de la tentative de déploiement sur heroku (fonctionne localement)