Re: Purging a replaced program
On Sat, 2002-02-09 at 14:28, Jaldhar H. Vyas wrote:
> On 9 Feb 2002, Jeff Licquia wrote:
> > And, lo and behold, /etc/init.d/webmin does exist in both packages, so
> > it should definitely not be removed.
> The thing is, I could swear that the conflict/replace/provide combination
> was enough to replace one package with another. Didn't that use to work
> or am I hallucinating?
Not to my recollection; at least, not this way.
The packaging system has no way of knowing, for example, if webmin might
create files outside of the package manager that are invalid or just not
used by webmin-ssl. In that case, the prudent thing is for dpkg to
leave those files alone and rely on the postrm to get rid of them when
> How can the packages know each other is installed? I can't call dpkg -L
> while in a maintainer script right? Would test -f
> /var/lib/dpkg/info/webmin.list be evil or is that ok?
If you control both packages, you could add a magic file to each that
would indicate one or the other; something like
"/usr/lib/webmin/webmin[-ssl]" combined with "if [ -e
/usr/lib/webmin/webmin-ssl ]; then..."
Or, you could look for /usr/share/doc/webmin-ssl. This could be risky
in the case of admins who like to rm -rf /usr/share/doc to save space.
Poking in /var/lib/dpkg/info can be risky because, as you've discovered,
package.foo files can linger in there even after a package has been
> Hmm I just tried this again and go the same results as before. Did you
> use dpkg -i or apt-get install? I used the former.
I used apt-get (with "-t unstable" to boot).
> Again I get the same results as before. This is with dpkg 1.9.19 on an
> uptodate sid system btw.
jeff@server1:~$ dpkg --version
Debian GNU/Linux `dpkg' package management program version 1.9.18 (i386).
This is free software; see the GNU General Public Licence version 2 or
later for copying conditions. There is NO warranty.
See dpkg --licence for copyright and license details.
This is on woody. Perhaps it's a new bug in dpkg?
> > I notice that the purge case for webmin's postrm does this:
> > test -f /etc/webmin/miniserv.users && rm -f /etc/webmin/miniserv.users
> > test -e /etc/webmin && rm -rf /etc/webmin
> > test -e /var/log/webmin && rm -rf /var/log/webmin
> > That's definitely incorrect in the case where webmin-ssl is installed.
> So here again I should check that webmin-ssl is installed first right?
That would be one way to do it. Another would be to have webmin-ssl use
> I hope the crypto in main issue gets resolved so I cn just drop this whole