[Perl] Installation oneliners (was:perldoc and perl/tk)

Tzafrir Cohen tzafrir at technion.ac.il
Tue Nov 26 01:48:53 PST 2002


On Tue, 26 Nov 2002, Reuven M. Lerner wrote:

> >>>>> "Shlomo" == Shlomo Yona <shlomo at cs.haifa.ac.il> writes:
>
>   Shlomo> Yes. You are correct.  RPMs and CPAN modules are not
>   Shlomo> synchronized.  I wonder how one can make the two methods
>   Shlomo> talk (if at all), so they share the same version/package
>   Shlomo> database.
>
> CPAN is just a distribution mechanism for Perl modules.There isn't
> any "CPAN database" installed on your system when you install a module
> from CPAN, although this isn't an inherently bad idea.
>
> When you install a Perl module, it is noted in "perllocal" (available
> by typing "perldoc perllocal").Programs can get access to it via the
> modules that Jaim and/or Shlomo mentioned earlier.
>
> The RPM database is basically a set of Berkeley DB files that files
> with packages.So RPM allows you to know that /usr/bin/perl is part
> of the perl-5.8.0-55 package.
>
> When you install a Perl module via RPM, the RPM installer doesn't talk
> to the Perl module installer.In other words, the module is then
> registered withRPM, but *not* with Perl's internal accounting system.
>
> Similarly, when you install a Perl module via CPAN.pm, no one tells
> RPM that new versions of various files have been installed on the
> disk. It's thus possible that RPM will think that a file exists, when
> it doesn't -- or that a file has been installed as part of an RPM,
> when it was, in fact, installed separately.

rpm generally tends to update the "system" copy of perl, and leaves the
site_perl part to CPAN. (didn't check this lately, but this is how things
*should be, at least). I believe that CPAN should be able to consider what
is installed in the "system" perl. Maybe it should assume nothing on the
modules that came there.

rpm, at least with newer versions from redhat and mandrake, maintains
dependencies between perl modules. That is, if one perl module requires
another, then the appropriate rpm packages will require/provide
perl(module::name) (or something similar). Other packages (e.g: packages
that include perl programs that use those modules) may require those
modules. I think that there are at least a number of non-module packages
sthat require module "requirements".

>
> So let's assume that you have a Red Hat system.It's quite possible
> to imagine the following scenario:
>
> - You install Red HatLinux, including Perl, via RPMs.
> - The module CGI.pm is installed as an RPM.
> - A new version of CGI.pm comes out, with a critical security fix.
> - Using CPAN.pm, you find that there's a new version of CGI.pm.You
> install it.  CPAN.pm now knows what version you've installed, and
> won't complain.
> - Using Red Hat's up2date service, you install the *SAME* new version
> of CGI.pm, overwriting what was there before.  Now the RPM database
> knows what version you're using.
>
> I don't think that anyone is working on combining these databases.
> But it would be nice if they would be smart enough to communicate with
> each other, in order to avoid the above scenarios.
>
> What a mess!

On my system I use strictly rpm (and create packages when necessary). I
still haven't made this as convimient as CPAN, though.

Still, it is probably quite possible to hack the CPAN module to produce
rpms from perl packages. If you're interested, please contact me for the
rpm-related parts (I don't know CPAN well)

-- 
Tzafrir Cohen
mailto:tzafrir at technion.ac.il
http://www.technion.ac.il/~tzafrir





More information about the Perl mailing list