Re: Replaces: and pre/post rm

[Richard A Nelson <cowboy@debian.org>]

On Fri, 15 Jun 2001, Julian Gilbey wrote:

> > > So was the <conflictor's postrm> actually called with the purge
> > > option?  It doesn't appear to have done.
> >
> > Not that I can find
>
> Good.

Indeed ;)

> > Since both packages must have the same postrm, and they remove *alot*
> > of files, things can get really nasty if I'm not careful:
> > 	1) Install sendmail
> > 	2) customize & play with things
> > 	3) Decide to install sendmail-tls
> > 	4) hrm, sendmail is no longer needed, but still has some conffiles,
> > 	   lets dpkg --purge it
> > 	At this point, many files in /etc/mail, /var/spool/mqueue, etc have
> > 	now been erased...  This what I don't want to happen to a user...
>
> Ah, very good point.  Why not simply add in the purge section a block
> around it which says:
>
> if ! [ -f <some file in the .deb which characterises the sendmail(-tls) packages> ]
> then
>     delete a lot of files
> fi

Because I have to allow for the user switching from non-tls to tls *OR*
from tls to non-tls.  The *only* differences in the contents of the two
packages are:
	* The binary (tls vs nontls)
	* Two conffile names:
		- /etc/cron.daily/$(package)
		- /etc/logrotate.d/$(package)
	* The $(package).buildinfo.Debian file in /usr/share/doc/sendmail -
	  but I can't use anything in doc to differentiate the packages.
>
> > > You might also be interested in the call:
> > >    <conflictor's-prerm> remove in-favour <package> <new-version>
> > > This might possibly help you.  See the policy manual, section 6.4.
> >
> > I'm perusing that now, it might help -- even if I simply rm'd the
> > older packages postrm file !
>
> No, no, no.  Don't ever fiddle with dpkg's internal databases like
> this.  (There is one very, very rare case I can think of in which this
> is necessary, but this isn't it.  And that is where the old prerm has
> a trojan or equivalent nasty in it.)

At this point, the cleanest approach seems to (me to) be:
	* drop dh_installcron/dh_installlogrotate and do the work by hand
	  using the same name (sendmail) for both packages
This'll mean that the packages will *NOT* have any unique conffiles,
and the replaced package *SHOULD* simply disappear --- I'm testing
that now.

Thanks again for your time, I've learned a fair bit more about packaging
and dpkg handling through this ;)
-- 
Rick Nelson
* aj thinks Kb^Zzz ought to pick different things to dream about than
   general resolutions and policy changes.
<Kb^Zzz> aj - tell me about it, this is a Bad Sign