http://qs321.pair.com?node_id=798628

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.