|
Posted by Tanel Kokk on August 19, 2005, 10:01 pm
Please log in for more thread options
Situation is as follows: module MIME::Base64 is perl standard module in
SuSE Enterprise Server. Module version is 2.21. Now I would like to use
program, which requires the latest version of MIME::Base64, version of 3.05.
What is the correct way to upgrade the module?
1) perl -MCPAN -e shell
At first I thought that this method should be most correct way, but what
about rpm dependecies, when there will be perl rpm package upgrade in
the future?
2) standard method: perl Makefile.PL && make && make test && make install
What do you think?
Tanel
|
|
Posted by Sherm Pendley on August 19, 2005, 5:01 pm
Please log in for more thread options
> Situation is as follows: module MIME::Base64 is perl standard module
> in SuSE Enterprise Server. Module version is 2.21. Now I would like to
> use program, which requires the latest version of MIME::Base64,
> version of 3.05.
>
> What is the correct way to upgrade the module?
>
>
> 1) perl -MCPAN -e shell
> At first I thought that this method should be most correct way, but
> what about rpm dependecies, when there will be perl rpm package
> upgrade in the future?
>
> 2) standard method: perl Makefile.PL && make && make test && make install
>
> What do you think?
I tend to look at package managers as an all-or-nothing affair - either I let
them manage everything, or nothing at all.
So, I'd leave the SuSE-managed copy of Perl strictly alone - there might be
other packages that depend on it in ways I'm not aware of. Then I'd install
my own Perl somewhere else, like /usr/local or /opt/perl, where I could do
as I please without fear of breaking or being broken by RPM.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
|
|
Posted by Scott W Gifford on August 19, 2005, 5:49 pm
Please log in for more thread options
> Situation is as follows: module MIME::Base64 is perl standard module
> in SuSE Enterprise Server. Module version is 2.21. Now I would like to
> use program, which requires the latest version of MIME::Base64,
> version of 3.05.
>
> What is the correct way to upgrade the module?
[...]
I use CPAN and configure it to install into /usr/local, then make sure
my scripts and/or my PERL5LIB environment variable use the local
directory first. The scripts pick up the newer modules, and RPM can
overwrite whatever it wants in the old location.
When I've installed over the one from the RPM, inevitably a newer RPM
comes out and screws everything up.
----Scott.
|
|
Posted by Tanel Kokk on August 21, 2005, 7:04 pm
Please log in for more thread options
Scott W Gifford wrote:
>
>>Situation is as follows: module MIME::Base64 is perl standard module
>>in SuSE Enterprise Server. Module version is 2.21. Now I would like to
>>use program, which requires the latest version of MIME::Base64,
>>version of 3.05.
>>
>>What is the correct way to upgrade the module?
>
> [...]
>
> I use CPAN and configure it to install into /usr/local, then make sure
> my scripts and/or my PERL5LIB environment variable use the local
> directory first. The scripts pick up the newer modules, and RPM can
> overwrite whatever it wants in the old location.
Mh.. I tried to make an rpm from newer cpan module (with perl2rpm). When
I installed it, it was installed into directory
/usr/lib/perl5/vendor_perl/5.8.3/*, while original module is in
directory /usr/lib/perl5/5.8.3/*. So there wouldn't be any rpm conflicts
(except man pages files, but these ones are not important)
Then I tested, which module perl program will use:
$ perl -MMIME::Base64 -e 'print $MIME::Base64::VERSION'
I got "2.21". So perl will use older module. Why?
What does these directory structures mean - site_perl and vendor_perl?
Tanel
|
|
Posted by Sisyphus on August 23, 2005, 10:48 am
Please log in for more thread options
>
> Mh.. I tried to make an rpm from newer cpan module (with perl2rpm). When
> I installed it, it was installed into directory
> /usr/lib/perl5/vendor_perl/5.8.3/*, while original module is in
> directory /usr/lib/perl5/5.8.3/*. So there wouldn't be any rpm conflicts
> (except man pages files, but these ones are not important)
Normally you'd update by using either method 1) or 2) from your first post,
instead of creating and installing an RPM. If you did that you might find
(I'm not sure) that the new version gets installed in
/usr/lib/perl5/5/8/3, overwriting the old version (2.21).
I don't understand why you don't want to do that - but that could be bad
understanding on *my* part as I've never had much to do with RPM's as
regards perl.
>
> Then I tested, which module perl program will use:
> $ perl -MMIME::Base64 -e 'print $MIME::Base64::VERSION'
>
> I got "2.21". So perl will use older module. Why?
Because that's the version it finds first. Perl goes looking through the
@INC directories, and uses the first MIME::Base64 it comes across.
If you print out the contents of @INC, you should find that
/usr/lib/perl5/5.8.3 is listed ahead of /usr/lib/perl5/vendor_perl/5.8.3.
>
> What does these directory structures mean - site_perl and vendor_perl?
>
There are conventions regarding just which @INC folder the various modules
go into. I'm not exactly sure of the rules that govern those conventions on
Unix type operating systems - someone else might provide them. As regards
functionality, it doesn't really matter whether a module gets installed into
perl5/5.8.3 or perl5/vendor_perl/5.8.3 or perl5/site_perl/5.8.3 or any other
@INC directory. As just explained it can have a bearing on which version of
a module gets found first, but the functionality of a module is not
dependent upon being in any *particular* @INC directory.
My feeling is that you could also solve your problem by removing the older
version of MIME::Base64. (Just rename Base64.pm to Base64.pm_bak - and
change it back to Base64.pm if you find you ever need to. No guarantees with
that - I personally get a bit nervous messing with installations that the
operating system uses.) Better still would be to build your own perl in
usr/local/lib, that you can mess with as you like without having to worry
about screwing up your operating system.
Cheers,
Rob
|
| Similar Threads | Posted | | perl upgrade, req to understand which modules to install | October 2, 2006, 2:54 pm |
| use CGI qw(:standard escapeHTML); | January 14, 2005, 2:54 am |
| Modules not installing to standard LIB directory | November 17, 2005, 8:14 am |
| CGI::Simple::Standard and CGI::Alert authors are unresponsive | July 28, 2007, 5:58 pm |
| [RESOLVED] DBD::mysql unresolved symbol _intel_fast_memcpy & mysql-standard-5.0.22-linux-i686-icc-glibc23 | August 29, 2006, 6:33 pm |
| Perl Module using XS | May 3, 2008, 5:09 pm |
| Perl module PDF::API2 | July 11, 2004, 5:35 am |
| Perl GD::Graph module: bug? | August 3, 2004, 8:42 pm |
| Installing DBI module for Perl 5.8.4 | October 4, 2005, 6:26 am |
| Problem with Net::SSH::Perl module | December 22, 2004, 12:38 pm |
|
XML Sitemap