[CentOS] PERL module woes

Fri Jun 2 01:29:46 UTC 2006
Jim Perrin <jperrin at gmail.com>

> I understand your point. Note Paul Heinlein's "laziness" comment later
> in this thread, and my inertia one in my original comment.

Ah the eternal motivator... or something like that...

> I'd have to create my own SRPM's to use rpm for my own rolled solutions,
> correct?

While I haven't done this with perl specifically ( I don't do much
perl work, so I suppose my ivory tower preaching here might be
considered hypocritical) many times you can simply modify an existing
srpm to use a new prefix value and install to /opt/ (/usr/local/ being
for source builds, which I discourage and avoid). In the event that a
new srpm needs to be created, it's really not that difficult most of
the time, as it's essentially creating a text file which does the
basic ./configure/make/make install for you. There are a load of
tutorials out there to walk you through this, and the folks in #rpm on
freenode (irc) are quite helpful generally.

> That would make maintainance of my system easier, correct?

It would allow you to produce a reliable build that you can duplicate
later if you need to, with more book-keeping information than is
available in a source build. If you return to cpan 3 months down the
road, your module or a dependency may have been altered, and you won't
necessarily have the same build across your systems. If you haven't
noticed, I'm anal about consistency. The rpm will also tell you when
something was built, who built it, what the build system was, all the
files included in the build and most things about them, permissions,
checksums and more so you know if anything has been changed.

> These are honest questions, but I just haven't had the time to learn how
> to build SRPMs given that all is working well for me now.

If what you have is working for you, there's no need to abruptly
change. Srpm construction can always help if you're working with an
rpm based distro so if you have a free minute it is worth learning.

Even if people don't always practice them, in my opinion they should
preach the good habits and know them. I find one of the things that
tends to hold people back is the assorted collection of bad habits
they tend to pick up and pass on when trying to get something working.
We've all done things the quick and dirty way, but there's no benefit
to passing those methods on to others. I tend to get irritable and
confrontational when I see people advocating what I consider to be
sloppy computing, because the people they're assisting may not
recognize it as a patch, hack or otherwise sloppy behavior. I will
correct people when I see this, and I fully expect people to correct
me if they see me doing it.

/Yes I like my ivory tower. Why do you ask? :-P

-- 
This message has been double ROT13 encoded for security. Anyone other
than the intended recipient attempting to decode this message will be
in violation of the DMCA