How to upgrade perl standard module?

[Tanel Kokk]

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

[Sherm Pendley]

Tanel Kokk <tanel.kokk.remove.it@mail.ee> writes:

> 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: [url]http://camelbones.sourceforge.net[/url]
Hire me! My resume: [url]http://www.dot-app.org[/url]

[Scott W Gifford]

Tanel Kokk <tanel.kokk.remove.it@mail.ee> writes:

> 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.

[Tanel Kokk]

Scott W Gifford wrote:

> Tanel Kokk <tanel.kokk.remove.it@mail.ee> writes:
>

>>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

[Sisyphus]

"Tanel Kokk" <tanel.kokk.remove.it@mail.ee>

>
> 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

[tanelko]

Sisyphus wrote:

> "Tanel Kokk" <tanel.kokk.remove.it@mail.ee>
>

> >
> > 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.

What if SuSE releases new perl rpm package, which for example fixes
some perl core bugs. Then my upgraded module MIME::Base64 will be
downgraded and I have to upgrade module again.

>

> >
> > 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.

I remember "from somewhere", that if perl use the latest version on
module. But it could be just my misunderstanding.

>

> >
> > 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.

As I said I wouldn't want to change files, which belongs to perl rpm's.
I think I resolve problem in that way:
- I'll make an personal rpm from new MIME::Base64 module with
PREFIX=/usr/local parameter
- I'll install it into /usr/local direcory structure
- and I'll use -I option to include /usr/local directory, when I'm
running perl program. With -I option directory will be in first place
in @INC array.


Thanks everybody!

Tanel

[tanelko]

tanelko wrote:

> I remember "from somewhere", that if perl use the latest version on
> module. But it could be just my misunderstanding.

Sorry! I wanted to say, that:

I remember "from somewhere", that should perl use the latest version of
module it finds from @INC. But it could be just my misunderstanding.

Tanel

[Sisyphus]

"tanelko" <tanel.kokk@mail.ee> wrote in message
news:1124804292.083298.291250@g47g2000cwa.googlegr oups.com...

>
> tanelko wrote:

> > I remember "from somewhere", that if perl use the latest version on
> > module. But it could be just my misunderstanding.

>
> Sorry! I wanted to say, that:
>
> I remember "from somewhere", that should perl use the latest version of
> module it finds from @INC. But it could be just my misunderstanding.
>

I don't know how that could be done. (I don't think it can.)

One thing that should work is if, instead of ''use MIME::Base64;" you code
it as:

require '/usr/lib/perl5/vendor_perl/5.8.3/MIME/Base64.pm';

Cheers,
Rob