Distributing Perl in a Linux distribution

gri6507 has asked for the wisdom of the Perl Monks concerning the following question:

Let me start of by apologizing if this question is inappropriate for this forum. I know in the past, I have been very successful at not only getting answers about specific perl programming questions, but also about the theory on how to properly structure perl programs. I hope that a question about the distribution of perl (the actual source tar ball available for download from http://www.perl.org/get.html) is still within the bounds of this forum.

I am a developer for an RPM-based Linux distribution. For obvious reasons, one of the RPMs we provide is for Perl. I have never questioned the content of the perl-%version.i586.rpm package until I ran into the following problem. The Perl tar ball includes the source for the perl engine itself as well as a number of "core modules". Therefore, when packaged, the resulting RPM provides perl itself and the multitude of included core perl(Module). However, I needed a newer version of one of those perl(Module) than what was available within the perl RPM. This left me with two choices, either rebuilding the perl RPM itself and explicitly updating that module's source, or creating a new RPM package for that one module. (I hope I haven't lost you yet).

So this brings me to my question. Why are there any "core modules" within the Perl source tar ball in the first place? Isn't it pretty much a guarantee that those modules will be obsolete well before the next version of Perl will be distributed with the updated version of those modules? Why wouldn't I, as an RPM packager, split out the main perl RPM to contain just the essentials of the engine and then provide individual RPMs for each of those "core modules"?

I thank you in advance. Looking forward to your ideas about this subject matter.

Comment on Distributing Perl in a Linux distribution

Replies are listed 'Best First'.
Re: Distributing Perl in a Linux distribution by Corion (Patriarch) on Oct 01, 2009 at 12:52 UTC
The core modules are either there because (mini)perl needs to run them to generate/compile the main perl executable, or they are there because they are considered to be essential to any Perl installation. There also are modules whose inclusion was a bad choice in retrospect, but a deprecation process has only slowly been started. I think the appropriate way is to create your own RPM for the updated module and install the updated module in `lib/site/`, so that it gets found before the old version under `lib/`. In addition, I would ask this question on p5p, as currently, there is a discussion on how to restructure and reorder the Perl installation directories, which will affect you once you distribute 5.12.	[reply] [d/l] [select]
Re^2: Distributing Perl in a Linux distribution by gri6507 (Deacon) on Oct 01, 2009 at 13:14 UTC
Thank you for the reply. The standalone RPMs for the core modules that I am talking about all deliver into lib/site, so our delivery/installation scheme is not a problem. However, I am a bit concerned about the future. Let me give you an example. Let's say I installed perl with its core modules into its standard built-in location. Then, I upgrade some module with a new version and place it into lib/site. Then, I upgrade perl itself to a new version with an even newer built-in version of that core module. Which version of the module would perl use then? I guess what I am asking is what's the search order of %INC? P.S. Thanks you for pointing me to the discussion about perl 5.12	[reply]
Re^3: Distributing Perl in a Linux distribution by Corion (Patriarch) on Oct 01, 2009 at 13:23 UTC
`perl -le "print for @INC"` [download] will tell you the module search order for your `perl` executable. I guess that you will have to maintain the dependencies you introduce yourself, or at least take some precautions in your RPMs. I don't know if RPM has a "provides" rule so you can say: `foo-2.0: # this is your added package perl-5.10.0: provides foo-1.0 requires foo-2.0 # so that RPM also pulls in foo-2.0 perl-5.10.1: provides foo-3.0 # and RPM will automatically remove the foo-2.0 p +ackage` [download] But again, I think I wouldn't try to fudge around with the Perl distribution itself but create an enclosing package that pulls in the required separate RPMs: `foo-2.0-meta: requires foo-2.0 requires perl-5.10.0` [download] That way, once you upgrade to `foo-3.0`, it could relax the requirement on the `foo-2.0` package and RPM could remove it from the system.	[reply] [d/l] [select]
Re^2: Distributing Perl in a Linux distribution by dolmen (Beadle) on Oct 01, 2009 at 14:57 UTC
No, the right place for distribution-packaged modules is `lib/vendor`. `lib/site` is for module that the admin will install without packaging (either manually or using CPAN/CPANPLUS).	[reply] [d/l] [select]
Re^3: Distributing Perl in a Linux distribution by Anonymous Monk on Oct 02, 2009 at 01:32 UTC
Correction :) `perl -V:installsitelib -V:installvendorlib` [download]	[reply] [d/l]
Re: Distributing Perl in a Linux distribution by Joost (Canon) on Oct 01, 2009 at 12:54 UTC
The reason the core modules are distributed with perl is that they're core modules: everybody who has perl installed should have those modules avialable, with at least that version, and all perl code can rely on those modules being there. (Linux) distributions can split up the core perl into different packages. Some distros split out the docs, development headers, debug info etc. Some distros also split out (some) core modules. While in theory that's a fine idea, in practice it leads to confusion when people install "perl" and then their code won't run. IIRC RedHat used to split out CGI.pm from the perl core, leading to lots of confusion with people just wanting to run a few CGI scripts. Anyway, what I personally do when I need an RPM of a CPAN package that overrides a core perl module, is to make sure the new RPM installs with INSTALLDIRS='vendor', or 'site', so it won't overwrite the core versions. As a last note: there really aren't that many core modules that are also on CPAN and are generally worth upgrading independently of perl itself. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: Distributing Perl in a Linux distribution by Bloodnok (Vicar) on Oct 01, 2009 at 13:00 UTC
I'm guessing that there are such things as core modules in a perl distribution to provide... A stand-alone useable installation (once compiled & installed) - providing a far simpler introduction since the intending user wouldn't have to download & install the perl compiler/toolset and then subsequently download & install modules - some of which may not work with the (version of the) toolset To provide a baseline of the above in order that the usability can, as far as humanly possible, be guaranteed and maintained with the distributed modules Recently I worked on a Solaris project (which uses ABI standard packaging) where I/we designed A package for the distribution plus a package each for the non-core modules A build process that downloads and translates the perl distribution (& modules) into packages for subsequent deployment and installation onto the target Or, put another way, designed our packaging to supplement, not ignore, the significant benefits of perl & the CPAN - why re-invent the wheel when perl/CPAN already has the majority of dependency tracking etc. implemented, all you need do is supplement the given dependencies where dependencies may be missing in the original. A user level that continues to overstate my experience :-))	[reply]

Back to Seekers of Perl Wisdom