Razor via RPM?

[Julian Field]

Scott Silva wrote:
> on 3-14-2008 9:39 AM Julian Field spake the following:
>>
>>
>> David Lee wrote:
>>> On Fri, 14 Mar 2008, Julian Field wrote:
>>>
>>>  
>>>> This actually creates a separate problem, that of all the perl modules
>>>> which react badly with the Perl RPM as they overwrite the same 
>>>> files. Do
>>>> I just try to find them and --force them like I do in the main
>>>> MailScanner distro?
>>>>
>>>> I've built all the spec files and can build the SRPMs very easily. But
>>>> I'm not convinced I'm not wasting my time...
>>>>     
>>>
>>> Thanks for the reply.  Appreciated.
>>>
>>> Let me re-word the overall issue at overview level:
>>>
>>> The aim is to make as easy as is reasonably possible a complete
>>> installation, especially on rpm-based systems.  Your existing scheme is
>>> hugely, hugely helpful in this!  Many thanks.
>>>
>>> o  MS is handled well by your distribution(s);
>>> o  Clam/SA is handled well by your (single) "tar" distribution;
>>> o  DCC follows well as a "wget ...; rpm -U ...";
>>> o  Pyzor follows well as a "wget ...; rpm -U ...";
>>>
>>> But Razor doesn't follow as easily.  A "wget ...; rpm -U ..." (from 
>>> Dag's
>>> repository) almost works, but not quite, because of those two perl
>>> packages.  The "wget... rpm..." sequence can be neatly automated under
>>> tools such as "cfengine".  But the Razor build is considerably more
>>> awkward and less straightforward.
>>>
>>>
>>>
>>> So that (as a high level overview) is the problem I'm trying to address
>>> (and before getting bogged down in the techy stuff).
>>>
>>>
>>>
>>>
>>> So now to the techy bog...
>>>
>>> Just a thought: suppose those two perl modules (Digest::SHA1 and 
>>> Net::DNS)
>>> were also included in your MS list (where the ".rpmmacros" mechanism is
>>> already in place).  Might that do the job?
>>>
>>> Following that MS install, there would be a potential sub-issue: 
>>> that of a
>>> subsequent Clam/SA install trying a re-install over the top.  (I guess
>>> you'd still want them in Clam/SA because that is where the true 
>>> dependency
>>> graph lies.)
>>>
>>> Suppose I offered to investigate bundling those two modules into the MS
>>> rpm-based install, and the possible knock-on interaction with a 
>>> subsequent
>>> Clam/SA install.
>>>
>>> Might that have a chance of flying?
>>>   
>> Just adding 2 modules to the MailScanner distribution sounds like a 
>> very quick hack to solve the problem. But would people prefer an 
>> RPM-based installation of the ClamAV+SpamAssassin installation 
>> anyway? I have a feeling it might cause more problems than it solves, 
>> as any perl upgrade would be even more complicated that it is now due 
>> to all the clashing modules that have to be removed and reinstalled.
>>
>> What are anyone's thoughts?
>>
>> Jules
>>
> I'm not sure if Dag's repo has an up to date spamassassin, but the 
> atrpms repo has the current version. If you want to stick with pure 
> rpm, it shouldn't be too hard to find a repo that can serve your 
> needs. I don't think Julian is going to want to go through all the 
> trouble to make rpms that will be right for every rpm based system, 
> and who is going to decide which one or two he is going to focus on?
> We already have gone through the Fedora VS CentOS debate many times.
>
I think it might be worth my while just adding the 2 troublesome modules 
to the MailScanner distro, as this is a very minor change that shouldn't 
cause any great problem and should just fix this issue. I've pretty much 
decided not to start distributing my own RPMs of clamav or spamassassin 
or all their pre-requisites, that's just too much work and is not really 
worth the bother.

Does anyone have the names of the 2 troublesome modules? I can't find 
the original list as this thread is getting pretty long :-)

Jules

-- 
Julian Field MEng CITP CEng
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

MailScanner customisation, or any advanced system administration help?
Contact me at Jules at Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
PGP public key: http://www.jules.fm/julesfm.asc


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.