7

How can I tell what modules were originally provided with the specific Perl installation on a machine?

(This is not a duplicate of: How can I tell if a Perl module is core or part of the standard install? ( "How can I tell if a Perl module is core or part of the standard install?" ) - it is in fact a spin-off question from it )

I am looking for what came with the installation originally, what modules were provided as part of that installation, what was built-in. NOT what has been installed since then.

I would like this to work with any Perl version.

I want to be able to do this:

  • using a script within a Perl program itself/command on the machine that has the installation. So for this I would be relying upon the installation to have a record in some form as to what it has originally.
  • on the downloaded package before I do the install. Ask it what modules it has.

The reasons why I want to do this is:

  • I want to know what modules I can expect as default when writing software to run on a machine with the Perl installation, and what modules I would need to add which aren't default
  • if I keep the original installer image/package OR know how to get the exact thing again online, then I have a repeatable consistent Perl installation for several machines with the knowledge of what modules will be present and what modules will not.
  • my Perl software will have a well defined deployment procedure as it is easy to define exactly what is required by the software
  • I may not be able to just update/upgrade the Perl version easily due to policies in place in my organisation (that's just the way it is, I don't want a side discussion on this). Such policy can be justified as there is always a risk upgrading to new software that can outweigh the benefits. Developers therefore need to know what they can expect to be available.

The reason why I ask this question is because, for any Perl version, there appears not to be an automated way of finding out the overall standard installation defining what modules you can expect to be present in your default installation on your machine - see question: How can I tell if a Perl module is core or part of the standard install? ( "How can I tell if a Perl module is core or part of the standard install?" )

The Perl versions cannot be relied upon to tell you what modules are present or not. Sure, there might be documentation online that tells you. But I need an automated way of doing this on the release I download/install. Even the same Perl version on different Linux/Unix distributions can be different.

Community
  • 1
  • 1
therobyouknow
  • 6,604
  • 13
  • 56
  • 73
  • 3
    Have you thought about using PAR or ShipWright? – Alexandr Ciornii Jan 18 '10 at 16:48
  • You already have the answer to this very general question. A better question, that has an answer, would be something like "How do I tell which Perl modules Debian came with?" – brian d foy Jan 18 '10 at 17:21
  • @brian d foy: Yes Debian certainly, but I need to be able to do this on various other distributions too, as commented on the question that this was spun-off of ( http://stackoverflow.com/questions/2049735 ) – therobyouknow Jan 18 '10 at 17:28
  • 1
    @Alexandr Ciornii: Thanks- I'll look into ShipWright, so far I have found: http://search.cpan.org/~sunnavy/Shipwright-2.4.4/ and for PAR, I have found: http://par.perl.org/wiki/Main_Page – therobyouknow Jan 18 '10 at 17:30
  • 1
    @Rob: Yes, I realize you want this for different platforms, but every platform (and every version of that platform) is going to have a different answer. You're not going to get better answers than you already have unless you narrow your question. – brian d foy Jan 18 '10 at 17:49
  • @brian d foy. "every platform (and every version of that platform) is going to have a different answer" +1 for the reality check. But that truth is very very unfortunate: what a messy dog's dinner deploying Perl is then! Definitely a disadvantage of using Perl among its many good points. What is the point of having release numbers at all? 5.8, 5.9 etc. And how confusing that they appear as 5.008.001 for 5.8, for example etc in some situations. I will look at @Michael Carman's and @gbacon's alternative approaches and report back. Once again, thanks everyone for input. – therobyouknow Jan 19 '10 at 11:57
  • @Rob: the situation you describe has nothing to do with anything Perl does. And vendor can do almost anything to anything they distribute, whether a programming language, font pack, or anything else. Perl provides a very nice standard that would work quite well if vendors used it. They change it, and that's the dog's dinner that the vendor gives you. I don't think you're getting that no matter how many times we say it: it's the vendors who repackage things that are making your life hard. – brian d foy Jan 19 '10 at 16:32

3 Answers3

6

For Debian or Ubuntu, you can use

$ dpkg --listfiles perl | grep '\.pm$'

For Redhat:

$ rpm -ql perl | grep '\.pm$'
Greg Bacon
  • 134,834
  • 32
  • 188
  • 245
  • On openSUSE: `> rpm -ql perl perl-doc|grep '\.pm$'` – daxim Jan 18 '10 at 17:11
  • 1
    These show you the files you have now, not for a pristine installation, don't they? – brian d foy Jan 18 '10 at 17:22
  • @gbacon Thanks. I'll have a look at what these do and come back a little later to see if there is any feedback on @brian d foy's question and more thoughts. – therobyouknow Jan 18 '10 at 17:35
  • @brian: No. I can't speak for Redhat, but in Debian `dpkg -L|--listfiles package` shows the files associated with _only_ that specific package. And in Debian, if you install other modules, they come from other packages. So, `dpkg -L perl` will show only the files in the base Perl installation. – Telemachus Jan 19 '10 at 19:25
  • +1 for your answer @gbacon I'm hoping that the resulting list is for a "pristine installation". – therobyouknow Jan 22 '10 at 16:31
6

In general you can't. You'll have a lot less frustration if you accept that and approach the problem from a different angle. Module::CoreList provides a list of what should be included in all installations as a bare minimum but vendors aren't required to adhere to that and most distributions include many modules that aren't part of the core. Barring building your own database of what was included in which version of each distribution -- a daunting task -- there's not much hope. Note that even for modules that came with a distribution the installed version might be different.

I can see a few different ways to approach this:

  1. If you know your target at development time (e.g. a specific version of ActivePerl) you can make decisions based on that.
  2. For the general case deploy your application like a module and specify dependencies. e.g. use Module::Build and list prerequisites in the requires section of the Build.pl script. The cpan shell can follow and resolve dependencies automatically.
  3. If you want to sidestep the issue entirely use PAR and Par::Packer to create self-contained deployment bundles.
Michael Carman
  • 30,628
  • 10
  • 74
  • 122
  • Thanks +1 - this looks good. I'll look into it a bit more when more time and follow up with more thoughts/decision. – therobyouknow Jan 18 '10 at 17:33
  • I've accepted this answer as it gives the widest scope of an answer, encouraging me to think around the problem. Credit and +1 to @gbacon too. – therobyouknow Jan 22 '10 at 16:30
0

am looking for what came with the installation originally, what modules were provided as part of that installation, what was built-in. NOT what has been installed since then.

Maybe for non-core modules you could parse perllocal.pod, seperating the initial batch of modules installed together with the Perl installation itself from later ones based on date. You're looking for lines such as:

=head2 Wed Apr 30 15:40:38 2008: C<Module> L<URI|URI>

So the first few would presumably be those that got installed with Perl itself and should have the same date (although not the same time of course). Those installed at a difference of 24 hours or more would be what you are looking for.

Not sure about core modules, as in my opinion the answers you got in the previous question you linked to are satisfactory, but clearly you didn't think so. Probably I'm missing something :)

Cheers, Offer

Offer Kaye
  • 179
  • 3
  • 1
    perllocal.pod is always bound to fail. It only works for those tools that care to update it, and not at all for the goody things users do by hand. – brian d foy Jan 18 '10 at 17:23
  • @solid-state: "Not sure about core modules, as in my opinion the answers you got in the previous question you linked to are satisfactory" - I agree the answers in http://stackoverflow.com/questions/2049735 are good (thanks folks) but the solutions only deal with relatively very recent versions of Perl which I think I will have to accept - this more to do with the way Perl is rather than the ability of the answer posters! @Michael Carman also takes this view above as part of his answer. – therobyouknow Jan 18 '10 at 17:39
  • @Rob: the solutions deal with most Perls released in the last 15 years. This isn't a porblem with Perl. You keep missing the fact that this is a problem with repackagers, which no one can prevent from breaking up and balkanizing what they distribute. – brian d foy Jan 19 '10 at 16:34