Re: Question about dpkg -r
Hope Duryea <hope_duryea@yahoo.com> writes:
> Hi all,
>
> I haven't read through the entire source, but from
> what I can tell by using dpkg -r on a package, and
> from looking at isdirectoryinuse(), and the call to it
> in remove.c, it seems the criteria for whether a
> directory is included in the removal of the package is
> whether any other package has installed into it. Is
> that correct?
yes. But beware of dpkg bugs that drop directories from packages
list. This causes some spurious "directory not empty" warnings when
running dpkg.
> If it is, I would like to suggest that it only do that
> for directories it created as part of the install. In
> other words, if it didn't need to create / or /usr,
> but did have to create /usr/share, then, when the
> package is removed, if /usr/share is now empty, it can
> remove /usr/share, but since it didn't have to create
> /usr or /, it should not (try to) remove those.
Say foo and bar both use /foobar/. When you install foo dpkg has to
create the directory. When you install bar the directory is already
there. When you purge foo the directory is not empty and fails to
rmdir. Now, when you purge bar it won't remove /foobar because
installing bar did not create it. You have a useless leftover dir.
The logic in dpkg is correct as it is. Directories like / or /usr will
always be used by some package so dpkg will never delete them. Any
extra logic about some dirs being special would only complicate the
matter.
> If that doesn't seem likely to happen, then is there
> any way I can provide dpkg with the list of files to
> remove and limit its action to just that list? I
> didn't see anything in the code to suggest it reads in
> a file (but again, I haven't read through all of it),
> nor have I seen anything in any of the documentation
> I've read through that would suggest I could, but I
> figured it doesn't hurt to ask :)
>
> Thanks,
> Hope
I don't see why it ever should be needed.
MfG
Goswin
Reply to: