[Ottawa-pm] Repackaging Perl modules (was Wanted: 5 Perl Programmers)
Yanick Champoux
champoux at pythian.com
Thu Mar 3 07:45:56 PST 2011
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
More information about the Ottawa-pm
mailing list