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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]