Re: package replacement and lack of disappearing...
On 6 Aug 2001, Robert Bihlmeyer wrote:
> Richard A Nelson <cowboy@debian.org> writes:
>
> > Nope... In this case, every conffile in one package is also in the other -
> > thats why the sendmail.list file became empty, and the package *SHOULD*
> > disappear.
>
> conffiles are /not/ the only distinction between removed and purged
> packages. A postrm can do other things on purge (e.g. delete logs)
> that I wouldn't want done automatically because of a conflict. Perhaps
> sendmail's postrm doesn't do anything like that, but dpkg can't know
> this. So this decision is punted to the user.
That makes sense, and no, sendmail's postrm is pretty basic. I could not
find any of this in the developer's guide... It seems to imply that if
all files in a package are replaced by a new package, the old package will
'disappear' and that is the behavior I was hoping for
> > 2) Why did the subsequent purge erase /etc/init.d/sendmail despite
> > the explicit exit 0 above
>
> This I don't know. I can't get any information on sendmail-tls. Where
> does this package hail from?
I've not released it - it can be built from the sendmail source (though
the rules file really sucks on the current versions - the new one is *MUCH*
nicer and will be released Sun/Mon).
--
Rick Nelson
It's a bird..
It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27
Reply to: