John Andersen wrote: > Theo Van Dinter wrote: > > The thing about package management is that either you need to use it, or > > you need to avoid it. Â Trying to manage a bunch of inter-related files, all > > in the same area of the file system, like perl modules, using different > > management methods, is like asking to be kicked in the head repeatedly with > > a pointy rock. > > That's just patently nonsense.
I agree with Theo. Having two management processes handle the same set of files is a setup for problems. Since rpm works by bookkeeping what has been installed and uninstalled it may be out of sync with what is installed by cpan which does not coordinate with rpm's database. I could contrive some examples of situations where problems could arise but don't have any real examples because I avoid doing it that way and so have avoided having problems. > Perl's method of detecting what is installed is perfectly compatible with > rpm installation. > > RPM may not be the wiser if you upgrade a perl module, but it will > not force you back level. At worst, it might do a redundant upgrade > if a later rpm becomes available. My experience has been different. But I am going to avoid debating that point and instead will debate a different one. One point that is often forgotten is that different sites will have different needs. Often what is perfectly fine practices at one site is completely inappropriate at another. For me I need to have perfectly repeatable installations. Machines installed or upgraded on Monday must be identical to machines installed or upgraded on Friday. Using rpm/deb packaging ensures this but using cpan does not. With cpan from moment to moment I might suddenly install a completely different set of modules. Most of the time things work fine but some of the time breakage will occur until the problems ripple through. It is bad for my career if I have to explain to my management why someone uploading a new perl module outside of our company caused software processes inside my company to break. They are expecting high reliability and I must execute appropriate behaviors to achieve it. If someone is managing a small home server they probably don't care about this level of stability. It is not the end of the world if some problems occur and you have to tinker around with it every so often to make it happy. Using cpan there is probably just fine and meets your needs fine. But if someone is managing systems at a large organization, especially with mail where system issues can cause large mail bounce or delivery problems, then deploying without testing is very bad. > I've been using a mix of CPAN and RPMs for year with spamassassin > and it has worked perfectly. I prefer cpan, but I'll use rpm if its > convenient. That's just patently insane. :-) Seriously though all generalities are false. The local admin needs to make a judgement call as to what is the best answer for their system. An informed choice is almost always better than a blanket set of general rules. There is no such thing as one size fits all. Bob
