Package: apt Version: 0.5.4 If I do "apt-get remove foobar" to remove a package "foobar" that has configuration files, those files remain. If I then realise that I actually wanted to remove those as well, and try to correct my mistake by typing "apt-get --purge remove foobar" as I should have to start with, I get the error message "Package foobar is not installed, so not removed".
This is at the very least confusing. The package is indeed "not installed" in one sense, having already been "removed" in that sense, but it's not as "removed" as I want it to be. apt-get seems to be refusing to act on the grounds that what I want done is already done, although what I want done is in this case *not* yet done. I note that dpkg is happy to purge a "removed" package, and successfully removes the remaining configuration files. I've been using this as a workaround, but I think I shouldn't have to drop down to the lower-level interface for this. I leave open the question of what apt-get ought to do about purging a removed package when the removal of the package caused removal of dependents. My feeling is that "apt-get remove foobar" followed by "apt-get --purge remove foobar" ought to always do the same thing as "apt-get --purge remove foobar", but that feels complicated, and I don't yet have a sufficiently deep understanding of the Debian package system to see what really ought to happen. Addendum: as I've said before in other bug reports, even if the consensus turns out to be that the code's behaviour is correct here, there's still a bug to be fixed. In this case two: the error message is misleading (if not outright factually incorrect), and the documentation really ought to explain such surprising behaviour and how to deal with it. -zefram
