[suggest] Clamav should not require a specific clamav-db version

[Andreas Rogge]

Dag Wieers schrieb:
> On Thu, 28 Feb 2008, Andreas Rogge wrote:
> 
>> Dag Wieers schrieb:
>>
>> I don't know where I read it, but somebody proposed not to output 
>> anything on rpm operations.
>> The problem is that you never know where your output will actually go. 
>> For example, if you use yum-updatesd, you will probably never see that 
>> output.
> 
> Right. That used to be the default, but remember that even Red Hat now 
> does it for openssh. :-)

That's not 100% correct. RedHat does it for openssh trigger, but afaict 
not for openssh itself. You'll see that openssh restarts when you 
upgrade glibc, which in fact is a trigger and not a post-script.

> 
> Of course if you do things in automated ways it is your responsibility 
> that you see the output. If yum-updatesd is sending my .rpmsave/.rpmorig 
> information to /dev/null, than I would never use yum-updatesd ever.
> 
> In fact, RPMs can provide output, but they should not ask for input. 
> That has always been the important difference between RPM packages and 
> what Debian did.

Agreed!
However, RPMs should not rely on somebody who actually reads the output, 
  because nobody can guarantee that. So you will still have breakage if 
people use tools that don't show the output.


> 
>> IMO people should know that services will be restarted on an upgrade, 
>> simply because that's the way it works.
> 
> It is not always that black and white. Not everybody knows that a 
> service is being restarted (and not always are services restarted when 
> you do condrestart). Also, if you install xinetd-services it reloads 
> xinetd, but what if xinetd because of that bails out ?

That's the same thing you have with openssh - I absolutely agree that
there should be some kind of information if rpm does unforseable things 
(i.e. upgrade package X will restart service Y). However, usually people 
who don't know that services might be condrestarted on an upgrade 
usually also don't really care :)

> Also if you are working in a big team, it is possible that not everybody 
> is aware of what services are enabled and also in that case it is useful 
> to see that the service has been restarted.
I somehow disagree here, because you actually should know what services 
are running on a box you upgrade.
But after all: point taken :)

>> For your example: if a service is misconfigured and it then breaks on 
>> an upgrade, I don't think it is a problem with the rpm, but a problem 
>> with the admin. If one really wants to catch such an issue, you'd have 
>> to write a pre-script that checks wheter the configuration is ok and 
>> stops the upgrade otherwise.
> 
> That is impossible to guarantee. 
That's my point.

 > I much rather play safe and let the
> sysadmin know we have restarted a service and it might have failed. So 
> at least he can check it.
Agreed - somehow - can't we just have something that informs the user 
only if something fails? I usually hit ugly issues (I somehow seem to 
attract them) and for me it seems to be a wrong information if you tell 
people that everything worked out fine without actually knowing it.
For example, I've seen vsftpd say "starting ok" and dying just a second 
afterwards because of a configuration problem.
So you have people looking at the update-process, seeing that all their 
services have restarted fine, but actually they didn't

My feeling was always that just staying quiet if everything seems to 
work out fine is the unix'ish way of doing user-interaction :)

Maybe we should use that behaviour and just say nothing if everything 
seems to work and just do some output if something fails or if we're 
doing unexpected things (see openssh, xinetd).

>> However, that solution doesn't really look good to me. So what we have 
>> currently should probably be enough.
> 
> No, I am convinced that we need to show service restarts even though 
> that was not the policy in the past. In a discussion a year ago others 
> agreed to it as well.
My concern is that if you provide too much information, people will stop 
reading it. If somebody starts with providing (verbose) information via 
rpm post scripts it would probably get abused very soon and you get 
somewhat debian-like updates where you have pages of text to read for 
just a single package-upgrade.

Andreas

-- 
Solvention
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info at solvention.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rpmforge.net/pipermail/suggest/attachments/20080229/5c6758ee/smime.bin