While I can't answer that, I might try to actually call a Perl check after which although slightly extra work would yield the answer.

Hmmm, good point - I could do that. I've come across several methods of checking module versions and none of them seemed "perfect" to me. Can you recommend a method?

You installing these locally in a non root users home? :)

If not, I can tell you that will wreak havoc if a Perl related updated comes down the pipe via yum...

We don't do auto-updates on production boxes so this is not a concern. And yeah, my other alternative would be to do it all via yum instead of CPAN, but that would be a massive change to the system I've inherited.

On Thu, Apr 15, 2010 at 04:31:08PM -0400, Alan McKay (alan.mckay@gmail.com) wrote:

...

While I can't answer that, I might try to actually call a Perl check after which although slightly extra work would yield the answer.

snip

We don't do auto-updates on production boxes so this is not a concern. And yeah, my other alternative would be to do it all via yum instead of CPAN, but that would be a massive change to the system I've inherited.

Correct me if I am wrong, but I was under the impression that this does not matter as the RPM's plug all the stuff into the correct locations for perl and the modules ... I use a lot of perl modules (e.g. for mimedefang, some online stuff I do etc) and cross upgraded a few machines, e.g. from FC6 to CentOS 5.4.

So the perl installation used to be totally CPAN based, now I upgrade most of the stuff from YUM. So far nothing has been broken and they are all rock solid.

So I would look for the RPM first, then for CPAN.

Jobst

-- ?Don't eat anything you've ever seen advertised on TV? - Michael Pollan, author of "In Defense of Food" _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Christoph Maser wrote:

Am Donnerstag, den 15.04.2010, 22:23 +0200 schrieb Alan McKay:

...

Hey folks,

Maybe there is a Perl/CPAN list that is a better place to ask this? If so, maybe someone can point me to it.

Anyway, I want to be able to script the installation of a bunch of CPAN modules, and the first basic problem I am coming up against is that the "cpan" command seems to always return 0 regardless of whether or not the install completed.

Google does not bring up a whole lot of help for me here, but I have to think this problem has already been solved.

Thanks for any guidance you can give.

-Alan

Alan

i do a lot of the perl CPAN RPMS at rpmforge, if oyu have any reasons to not use them please tell and I will try to fix that.

The main problem with 3rd party repos is that you have to be careful about updates causing dependency conflicts, especially if you use more than one. I normally leave the repos disabled in the yum config and explicitly use "yum --enablerepo=reponame install packagename" to pull only the packages I want and look carefully at the list of dependencies.

On 4/16/2010 9:46 AM, Joseph L. Casale wrote:

...

The main problem with 3rd party repos is that you have to be careful about updates causing dependency conflicts, especially if you use more than one.

You've mentioned that before, doesn't 'priorities' resolve this nicely? I use c5-testing, rf, atrpms, epel, remi and some others and never have issues.

Only if you actually know the right settings, which you have no way of knowing because they are different from package to package and sometimes from day to day.

There are some duplicate packages in those, but careful picking makes it a non issue.

Yes, careful picking is the point - but you are picking from separately moving targets. For example, a lot of things you may have installed from centos extras are now duplicated in epel with some incompatibilities. And there are odd couplings: for example if you use subversion from rpmforge to get a version that is not insanely out of date and also run viewvc, you would have gotten the rpmforge viewvc a few months ago, but now the epel version would try to update it with an incompatible configuration.

Sorry, sent too soon. As for your problem with not knowing if the module was succesfully installed... i went around by trying use/require and printing version after each install.

Tomas

Fri, Apr 16, 2010 ve 03:26:16PM +0200, Tomas Ruprich napsal:

Hi, i don't know exactly if this would be usable for yourself, but very nice feature for our purposes is autobundling, see for example: http://search.cpan.org/~andk/CPAN-1.9402/lib/CPAN.pm#POPULATE_AN_INSTALLATIO... or http://www.developertutorials.com/tutorials/cgi-perl/automate-perl-module-de...

As for RPMs, it could be sometimes problem with versions. RPMs aren't often the most recent versions of modules and resolving RPM dependencies could sometimes overwrite the most uptodate versions (which you need) by slightly older which may not be applicable. But this really depends...

Tomas

Thu, Apr 15, 2010 ve 04:23:32PM -0400, Alan McKay napsal:

...

Hey folks,

Maybe there is a Perl/CPAN list that is a better place to ask this? If so, maybe someone can point me to it.

Anyway, I want to be able to script the installation of a bunch of CPAN modules, and the first basic problem I am coming up against is that the "cpan" command seems to always return 0 regardless of whether or not the install completed.

Google does not bring up a whole lot of help for me here, but I have to think this problem has already been solved.

Thanks for any guidance you can give.

-Alan

-- ?Don't eat anything you've ever seen advertised on TV? - Michael Pollan, author of "In Defense of Food" _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 04/17/2010 12:21 AM, Alan McKay wrote:

Now my only problem seems to be that cpan does not allow me to specify "yes" to this question when it asks. e.g. like the "-y" option to "yum"

---- Unsatisfied dependencies detected during [A/AN/ANDK/CPAN-1.9402.tar.gz] ----- Test::Harness Shall I follow them and prepend them to the queue of modules we are processing right now? [yes]

Any way to do that?

Try piping the output of the 'yes' command to whatever script is asking the question. "man yes" for more details ;-)

Kal

I think this could be done by

cpan> o conf prerequisites_policy follow cpan> o conf commit

and then set

env PERL_MM_USE_DEFAULT=1 cpan or env PERL_MM_USE_DEFAULT=1 perl -MCPAN -e shell

Tomas

Mon, Apr 19, 2010 ve 04:24:21PM -0500, Les Mikesell napsal:

On 4/19/2010 4:15 PM, Kahlil Hodgson wrote:

...

On 04/17/2010 12:21 AM, Alan McKay wrote:

...

Now my only problem seems to be that cpan does not allow me to specify "yes" to this question when it asks. e.g. like the "-y" option to "yum"

---- Unsatisfied dependencies detected during [A/AN/ANDK/CPAN-1.9402.tar.gz] ----- Test::Harness Shall I follow them and prepend them to the queue of modules we are processing right now? [yes]

Any way to do that?

Try piping the output of the 'yes' command to whatever script is asking the question. "man yes" for more details ;-)

I thought that was one of the things you could set to default to 'yes' when you initially configure the cpan module, but it's been a long time since I did that.

-- Les Mikesell lesmikesell@gmail.com

OK, now I have this question when applying the autobundle I created, and I'd like to default it :

Running the test suite is important to make sure that the module that you are about to install works on your system. If you choose not to run the test suite and you have a problem using this module, make sure to return and run this test suite before reporting any problems to the developers of this module.

Skip the test suite? [No]

On Fri, Apr 16, 2010 at 9:26 AM, Tomas Ruprich ruprich@uikt.mendelu.cz wrote:

http://www.developertutorials.com/tutorials/cgi-perl/automate-perl-module-de...

I am curious if you or anyone else is doing this. I spend all day yesterday on it - the scirpts as given just simply do not work and are far too simplistic - so I expanded upon them quite a bit but still find this method does not work.

This is still an issue for me unfortunately - I like the idea of the above approach where I keep all the module tarballs on hand and build them myself manually. But I cannot seem to get it to work. The above article for example makes no mention about what to do about modules that want to include other modules.

If you are going to put any work into it yourself, you really should set up a local yum repo and either copy in rpms from epel/rpmforge if they exist or use a CPAN->rpm tool to build them if they don't or you want something newer.  Then installing on any target machine is just "yum install list_of_packages" which is easy to script and will always have reproducible results.

I'm leaning pretty heavily in this directly actually, just given how little progress I'm making with CPAN itself. Next step I guess is to see if all my packages are available in RPMs.

The only downside I see of this approach is that it becomes far more complex in a non-homogenous environment. We're almost all on Centos 5 at this point, but we do still have a few dribs and drabs of other things out there. But still I think it will be managable.

Am Mittwoch, den 21.04.2010, 18:16 +0200 schrieb Joseph L. Casale:

...

I'm leaning pretty heavily in this directly actually, just given how little progress I'm making with CPAN itself. Next step I guess is to see if all my packages are available in RPMs.

rpmforge has a lot, the only pain you might encounter is the circular dependency hell you sometimes encounter building rpms with cpan2rpm, but it's probably worth the onetime effort...

I have not seen that yet. Is that specific to cpan2rpm?

Chris

financial.com AG

Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553