Re: Replaces: and pre/post rm
On Thu, 14 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
> > The few conffiles are because the corresponding dh_ commands don't allow
> > me the choice of renaming the script (ala dh_installinit).
> >
> > That leaves me with the ${package}.postrm, which I guess will have to
> > contain all the intelligence to:
> > *) If the alternative package is installed, do nothing
> > *) If the alternative package is *NOT* installed, kill straggling
> > files.
>
> Why? When one of the packages is finally purged, surely that will do
> the job of cleaning out any mess from either of them (as you appear to
> indicate that they use the same manually created files).
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...
> 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 !
> > I guess, given that, I could even have ${package}.postinst issue
> > a dpkg --purge for the alternative package...
>
> Yuck -- no way!
;-)
Thanks for your time, this is helping me a lot !
--
Rick Nelson
> Alan Cox wrote:
[..]
No I didnt. Someone else wrote that. Please keep attributions
straight.
-- From linux-kernel
Reply to: