On Mon, Dec 01, 2003 at 02:39:29PM +0000, Graham Murray wrote: > "Logan Harbaugh" <[EMAIL PROTECTED]> writes: > > > I had to locate the RPM on the RedHat disks, install the package, > > then go back and then install the dependencies that hadn't been > > installed in the first place. Then I had to go through the > > documentation and see what files needed to be changed and how, make > > those changes, and then test the result. The whole process took me a > > little over an hour. > > Would it not have been a lot simpler to just done > > #perl -MCPAN -e shell; > cpan> install Mail::SpamAssassin > > which is the 'standard' way of installing almost any Perl based > package?
This can be problematic under many distribution's package control. SpamAssassin has numerious dependencies, including a SA-patched version of Perl module, and very often install Mail::SpamAssassin must be accompanied by several other install commmands. If you regularly install security upgrades from your vendor, it is a very good idea to locate all vendor packages containing anything installed under CPAN, and one way or another mark them installed but on hold. This prevents your regular vendor upgrades from overwriting and possibly downgrading SpamAssassin dependencies. The second alternative is to compare in detail the CPAN versions to the vendor versions of all dependencies, wrapping the CPAN packages in the vendor build scripts for each package that must be newer than the vendor-supported release, then using the vendor build procedure rather than CPAN's. This can be laborious. For most vendors there are unofficial troves of newer-than-vendor stuff which can be used to bridge any gaps. Another alternative is using /usr/local builds of CPAN things, checking to see that there aren't parallel but older versions of each installed from vendor sources, and if need be uninstalling the vendor sources, or constructing a full replacement for Perl and its modules under /usr/local and forcing SpamAssassin to load first from there. This again can require some time-consuming attention to details. Or, you can just say "damn the torpedos" and install from CPAN over the top of the vendor installation, trusting that if anything gets downgraded during the next vendor upgrade, either you'll notice it breaks and be able to fix it, or it won't break. Or maybe just stop applying vendor security upgrades. None of these is foolproof. The underlying problem is that two different configuration management systems unaware of each other's workings, controlling possibly overlapping sets of modules, can step on each other. Many well-informed and security-conscious professionals conclude that the best option is to stick with only one method of managing configuration, and pick the one that manages versions of most of the software on their systems. This is the course Mr. Harbaugh followed. I happen to favor the freeze-the-vendor-versions approach, simplifying it by marking Perl and _all_ modules as installed but on version hold, then using CPAN exclusively for all Perl related upgrades. But other people's mileage will vary. It's easy to chew up an hour with any of these approaches. -- Dan Wilder <[EMAIL PROTECTED]> ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
