One common way to package for the version you want to distribute is to install your perls with version suffixes. You can set that up at Configure time. Then when you wish to package or install for the earlier version, just call the perl you want, for example, $ perl5.8.1 Makefile.PL

For extra confusion ;) read about installstyle in Config, and about "PREFIX and LIB" in ExtUtils::MakeMaker.

I would highly, highly recommend not doing that. Running your development and production boxes on different levels, that is. What if, for example, you triggered a perl memory corruption that has been fixed (common problem here)? So, if you're using perl 5.8.6 in development, you never see the problem. As soon as you put it in production on 5.8.0, bam!, core dump. Now you're scrambling to recover since your production server isn't working anymore.

Better to use the same level on both boxes, find the problem in development, and come up with a plan to get your software working in production. This can be a plan to upgrade the world to 5.8.1 or 5.8.6 or anything in between, or it can be a plan to try to not do whatever causes the memory corruption (e.g., don't use as many globs - I had that problem in 5.8.0, and this was my solution since 5.8.1 wasn't out yet). But it will be a plan, and one you can execute quickly with a reasonably well-known downtime for your production server. There will be fewer gotchas and surprises at the last minute - which is always a good thing. You can have all of management buy in to the plan. And they will be much happier with known issues than they will with unknowns that jump up and catch them. What if someone had a critical need for the production server you just took down 30 minutes after you took it down? By having a reasonable estimate of the affects of an upgrade, you can tell everyone that the server is going to be unavailable for that time period, and can negotiate a time for the upgrade that is appropriate, rather than surprising everyone with that crash.

Yes, I'm rambling. It's that important.

My machines really have four different roles: production, testing, build, and development. I think your first paragraph is arguing for the same version on testing and production, which I certainly agree with -- I also am very familiar with memory corruption bugs in various version of Perl. (Including some that haven't been fixed as of 5.8.5...) And my original question is irrelevant if I run the same version on my build box as on the production boxes.

I certainly don't want to always run the same version on my development box as on the production box; I'd never be able to upgrade that way. But I don't think that's really what you're saying.

So I think you're right, in that it shouldn't really be an issue. I ought to build the RPMs on both the build and development boxes, and install the build box's version on testing and production, and the development box's version on development. The problem is, I'm lazy and don't really have a distinction between development and build boxes most of the time. Not only that, but I can't tell from just the RPM filename what version of Perl it was built for. So I keep running into problems where I keep trying to install the wrong RPM on the wrong box. (Dependencies catch the problem, assuming I'm not being stupid and using --nodeps. Which I often am. But I still end up copying the wrong RPM to the "install all these on this box" directories.)

Considering that most of these are pure-perl, noarch RPMs, it's annoying -- the bits are identical, but they go into different directories according to what are supposed to be versions of Perl with identical public APIs.

Actually, I didn't realise you had four roles, and thus four (or more) machines. But, given that new piece of information, I would argue that keeping them all in sync is a good idea, too.

This doesn't mean you can't upgrade. It means that you plan and schedule your upgrades. You plan an upgrade to your dev box. If your white-box testing fails to find problems, you then proceed with build/test upgrades. Once everything is tested satisfactorily, you proceed with the production upgrade. Everyone (all affected parties - mostly managers) has buy-in at each stage. If intractable problems are found (hopefully prior to production), you roll back to the previous level. Perhaps you get to that point, and decide to try a different level. But your production server isn't affected until you have something that works.

And, yes, this makes the whole initial question pretty much moot. :-) That's kind of the point - to solve the problem in such a way that lots of problems are solved, rather than a band-aid for just part of the problem. Otherwise, you end up in a project of band-aids, rather than a robust, well-tuned machine. Remember - the point isn't to write code, but to produce revenue. And I presume that the production server is critical to that last part.

$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuratio
+n:
  Platform:
    osname=linux, osvers=2.6.4, archname=i586-linux-thread-multi
    uname='linux g194 2.6.4 #1 smp fri jan 14 13:01:26 utc 2005 i686 i
+686 i386 gnulinux '

<snip>

Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL
+_IMPLICIT_CONTEXT
  Built under linux
  Compiled at Feb  5 2005 12:25:37
  %ENV:
  @INC:
    /usr/lib/perl5/5.8.3/i586-linux-thread-multi
    /usr/lib/perl5/5.8.3
    /usr/lib/perl5/site_perl/5.8.3/i586-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.3
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.3/i586-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.3
    /usr/lib/perl5/vendor_perl

$  cat /proc/version
Linux version 2.6.4-52-default (geeko@buildhost) (gcc version 3.3.3 (S
+uSE Linux)) #1 Wed Apr 7 02:08:30 UTC 2004
[download]