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 _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
