Re: Question about dpkg -r
The problem is my /usr is actually a symlink, and
despite the fact that it has lots of files and other
subdirs in it (in the real dir it's a link to, that
is), dpkg -r does remove it. So I was trying to think
of some way to prevent that happening.
There's this comment in remove.c:
/* Only delete a directory or a link to one if we're
the only
* package which uses it. Other files should only be
listed
* in this package (but we don't check).
*/
There isn't a test up-front to see whether the dir (or
the dir the symlink points to) is empty -- rmdir() is
called just if no other package is using it, and a
test is then done to see if errno was ENOTEMPTY. But
when rmdir() is used on a symlink, it just removes the
symlink and doesn't touch the real dir, so ENOTEMPTY
isn't going to happen. And I can't have it removing my
/usr symlink, since that seriously messes up my
environment.
I understand what you're saying wrt pkg A v. pkg B,
but as it stands now, I simply can't use dpkg (or
apt-get) to remove a package, which means I can't
really use dpkg (or apt-get) at all. So I need to come
up with some solution -- because I would like to use
it.
Maybe a --files-only flag for remove (which would
include symlinks to only files)? Or maybe there could
be some non-package-specific record of the dirs (and
symlinks to dirs) that dpkg did create, and when
removing a package, if the dir or symlink isn't on the
list, skip it?
Hope
--- Matt Taggart <taggart@debian.org> wrote:
>
> Hope Duryea writes...
>
> > 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?
>
> Not just other packages, but also if anything
> remains in the directory, like
> files a sysadmin put there, or installs outside the
> packaging system, etc.
> Maybe that's what you mean, I just wanted to be
> clear.
>
> > 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.
>
> What about the case where package A is the first
> things to install something
> to /usr/share (and thus created it) and then package
> B installs something
> there. Then you remove A first and then B. A created
> it but B still needs it
> so you can't remove when removing A, and if you're
> only removing directories
> if a package created them then it wouldn't be
> removed with B. The current
> method of checking if a directory is empty each time
> a package removes it's
> last file from it seems like the most
> straightforward way.
>
> > 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?
>
> What behavior are you trying to get? To not delete a
> directory you still have
> non-package-system files in? It won't. To leave an
> empty directory? If you
> want that, would touching a file in that dir to make
> it stick around work?
>
> > 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 :)
>
> I haven't read the dpkg code, my comments above are
> just based on observation
> of using dpkg for a while. Often when dpkg is
> removing packages you will see
> it report "not removing blah, directory not empty".
>
> --
> Matt Taggart
> taggart@debian.org
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Reply to: