[Ottawa-pm] Repackaging Perl modules (was Wanted: 5 Perl Programmers)

[Yanick Champoux]

On 03/03/11 08:25, Michael P. Soulier wrote:
> On 28/02/11 Yanick Champoux said:
>
>>      Could be worse. I had to hack a wee bit in Perl 4 last year. No,
>> seriously, I did. I felt like Indiana Jones and the Codebase of Doom.
> Yikes.

     That was epic, and will indubitably stay as one of my favorite war 
story evah.


>
> It's different when you own the OS, sort of. Our infrastructure expects rpms
> and any attempt to go around standard conventions is highly criticized.

     Mind you, installing your own perl doesn't preclude you to bundle 
that rogue instance as rpms. The gain is simply that those rpms install, 
say, to /opt/<your_company> instead of polluting the main system.

     Now, if the Power That Is is telling you that you can't install in 
exotic locations, but can't disturb the main system either, well, in 
that case, you're a little bit caught in a Yossarian's situation. I 
recommend beginning to swim toward Switzerland. ;-)


> CentOS
> is old enough in its tracking of packages that I'm constantly tempted to ship
> my own interpreters but thus far I don't. We don't need ten apps all wasting
> disk space shipping all their own base.

     True. At the price and size hard disk are nowadays, we wouldn't 
want to waste a full 100 megs needlessly.

     ... okay, okay, put down that rock. I know there are circumstances 
where HD space *is* a consideration -- I'm just taking the mickey of all 
the PHBs who recoil in horror at the thought of bundling a perl with 
their app, and yet turn around and don't see any problem whatsoever 
deploying java applications that weight twice that size.

     Mind you, you could already address part of the additional size 
issue by having a single codebase under '/opt/<your_company>' -- you 
don't duplicate for each application, and yet you free yourself from the 
system's code corset.

Joy,
`/anick