resolving rpm conflicts

Nifty Hat Mitch mitch48 at sbcglobal.net
Sat Aug 7 19:14:34 UTC 2004


On Sat, Jul 31, 2004 at 06:39:02PM -0500, Steven Stern wrote:
> From: Steven Stern <subscribed-lists at sterndata.com>
> To: For users of Fedora Core releases <fedora-list at redhat.com>
> Date: Sat, 31 Jul 2004 18:39:02 -0500
> Subject: Re: resolving rpm conflicts
> Reply-To: For users of Fedora Core releases <fedora-list at redhat.com>
> 
> On Sat, 31 Jul 2004 19:43:06 +0200, Alexander Dalloz
> <alexander.dalloz at uni-bielefeld.de> wrote:
> 
> >Am Sa, den 31.07.2004 schrieb Steven Stern um 19:28:
> >
> >> When I try to install the latest clamav and clamav-milter rpms from the
> >> crash-hat repository, rpm reports that they conflict with logwatch. If I try
> >> to update logwatch from Dag's, it reports a conflict with the two clams.  Is
> >> there any easy way to force these things to work or tweak things so they work
> >> and play well together?
> >
> >>    Steve
> >
> >Which crash-hat ClamAV do you use? I don't get conflicts and from
> >changelog a conflict was solved with version 0.73-1, see
> >
> >http://crash.fce.vutbr.cz/crash-hat/2/clamav/clamav.spec
> 
> It started happening, I think, with .74. I'm now on .75.1, using the RPM
> install of logwatch 5.2 linked from logwatch.org.
> --

I see the problem that Steve is reporting.

# rpm -Uvh logwatch-5.2.2-1.noarch.rpm
Preparing...                ########################################### [100%]
  file /etc/log.d/conf/services/clamav.conf from install of \
    logwatch-5.2.2-1 conflicts with file from package clamav-0.75.1-1
  file /etc/log.d/scripts/services/clamav from install of \
    logwatch-5.2.2-1 conflicts with file from package clamav-0.75.1-1

It is clear that I could copy the existing files to a safe place and
then force an update to logwatch.  Then I can compare the old and the
new.  Recent attempts to overflow a buffer in web servers are
generating 'ugly' log messages that the new logwatch is suposed to
sort out.  The nunmber of these seems to double once a week.  For me
it is time to clean up logwatch because I know what these are and that
I no longer care because they pose no threat.

I do have the logwatch tar ball.  It should also be possible to
see what I need to update in logwatch by hand to solve my
apache log garbage messages.

Perhaps I should also check or an update to logwatch in test...

-- 
	T o m  M i t c h e l l 
	Just say no to 74LS73 in 2004





More information about the users mailing list