On Tue, 8 May 2007, John Hearns wrote:

> Jon Peatfield wrote:
>
>>  Considering the case of an update to 'openssl', there are many
>>  packages which depend on it, and several of these have
>>  services/daemons.
>>
>>  However, as far as I can tell none of them have any obvious
>>  '--scripts' or '--triggers' which will cause those to be re-started
>>  if openssl is updated.
>> 
> Adding a somewhat idle comment to this thread,
> I once had a spirited discussion with a Debian developer (Phil Hands).
> He sang the praises of dpkg which is claimed to always restart services such 
> as sshd following an update, versus rpm which does as you describe.
> I guess he was right.
>
> To be fair, its not the actual mechanics of rpm versus dpkg, more Debian's 
> rigid adherence to the rules.
> (Did i really just praise Debian over the right and natural way of RPM based 
> distros? Need that first coffee of the morning to bring reality back into 
> focus).

I'm not sure that it is actually possible to (easily) do the right thing 
using *just* the infrmation that rpm has.  I'll try to find a Debian 
expert to explain to me what data they use...

Just to confuse things (ha), glibc is a special case in that updates to it 
run a piece of code which restarts sshd (and possibly other things).  That 
there is a special-case-hack for glibc shows a lack of a better 
mechanism...

None of that would be needed if there was an automatic way to restart 
services which depend on code/library which is altered/updated.

Now in some cases one could fake up the 'right thing' (whatever that is), 
but then it would catch alterations due to prelink etc.

I'm starting to think that (if one is running prelink) then restarting 
things using the altered libs is probably *roughly* right -- though there 
are probably edge cases where it certainly isn't what is wanted!!

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/