RPM packaging of modules and multiple perl versions

[Anonymous Monk]

Hello Monks,

In an environment where there are multiple versions of Perl installed (for the moment lets just say two: the system perl and the latest, stable perl...I'll call this last one the developer perl) what is the recommended way to build and RPM package CPAN modules? Should the system perl and the developer perl share modules (and therefore packages for modules)? What about modules that are compiled and (may) need to be compiled against a specific perl? So far the only solution I've come up with is an entirely different naming scheme for the developer perl's RPMs: the system perl's RPMs are named f.e. perl-Module-Build whereas I'd name the developer perl's module <company>-perl-Module-Build. This doesn't seem like the best solution but I have been unable to find any solutions using Google and the like.

So what recommendations are there for a) proper way to build modules for the above situation and b) the naming scheme for the RPMs.

Thanks.

[danb]

I do not recommend trying to share modules (packages) at all -- use the entirely different naming scheme to keep things sane. Your <company>-perl-* is good. Another is "local-perl-*", used for example here:

http://packages.endpoint.com

That installs local-perl-Module-Build to /usr/local/, and it can be installed at the same time as perl-Module-Build (/usr).

[Anonymous Monk]

Thank you for the reply.

The <company>-perl-Module-Build solution works well for my simple scenario. But I don't think it scales to more than two perl's on one machine. What if I have the system perl (perl-5.8.x), developer perl 1 (perl-5.10) and developer perl 2 (perl 5.12). What is a good way to deal with this? I think taking the RPM naming approach to its logical conclusion means I end up with three packages for the same module, one for each version of perl. Is this what people actually do? I can see the advantage but it seems like a hell of a lot of duplication of effort.

[brycen]

I'd say sharing modules is setting yourself up for a world of hurt eventually.

Those perl versions must be separate for a reason (or why would anyone bother making them separate?). They need to have matching separate perl modules.

Can you get away with using CPAN exclusively for the developer perl, and only packaging up the stable production perl modules as RPM's? If you go through the trouble of packaging up, would your bosses let you contribute those packages back to your distribution maintainer for others to use?

[Anonymous Monk]

I'd say sharing modules is setting yourself up for a world of hurt eventually.

Those perl versions must be separate for a reason (or why would anyone bother making them separate?). They need to have matching separate perl modules.

Can you get away with using CPAN exclusively for the developer perl, and only packaging up the stable production perl modules as RPM's? If you go through the trouble of packaging up, would your bosses let you contribute those packages back to your distribution maintainer for others to use?