[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#156463: dpkg: Doesn't replace obsolete dirs with symlinks on upgrade

Josip Rodin wrote:

On Tue, Aug 13, 2002 at 06:51:31PM -0400, Adam C Powell IV wrote:
dpkg doesn't know or doesn't have a guarantee that there isn't actually
anything within the directory that you want to remove, so it doesn't try it.
I don't understand. "dpkg --remove libc6-dev" *does* remove the /usr/include/asm/arch directory (and its parent too). But with that directory in existence (i.e., with the old package installed, not removed), "dpkg --install libc6-dev_2.2.5-13_arm.deb" does *not* remove the directory and replace it with the symlink in the new package as it should.

So --remove knows to remove the directory (knows that there isn't anything there and that it's unique to this package) and a subsequent --install succeeds. But upgrade fails, and causes breakage if something with the same name was supposed to replace the directory. How is this not a bug?
I didn't say it wasn't :)

Okay, I'm sorry, I misunderstood.

Arguably it could go check, but I guess there's a reason against that if
nobody did that yet.
So upgrading doesn't remove *any* directories while upgrading? I'm curious, why not just do the --remove and --install, is there such a big performance hit associated with removing and creating directories?

Please clarify.
It's not about performance, it's about clashes. If a package places files in
/foo, and another package too, and then the other package changes /foo into
a symlink, dpkg shouldn't just stomp over the first package's files.

Again, the special case where /foo is empty is what sounds straightforward
to fix. But it also may not be that easy, since maybe another package
installs /foo as empty and doesn't _want_ /foo to ever point anywhere else.
I don't know.
Okay, I get the gist of the motive, but don't see the justification. If this is the case, then why does --remove remove the dirs? After all, another package might someday want them to be there. And if another package currently has files there, then it won't be removed, right?

So the answer to "why not upgrade by --remove and then --install" (or equivalent behavior) is because another package *might* *later* want to create that dir and leave it empty?

I guess part of the answer is something like "directory symlinks just plain screw up package management", that is, there will always be an exception which breaks somebody's desired behavior. :-)

But back to the bug, if we're going to have directory symlinks at all, I really don't see how this remote exception justifies the current problem, which causes other serious breakage.

And the $64,000 question is: does this merit reopening the bug, or the time required to "fix" it? Or does policy ban directory symlinks -- or should it? (In which case I should reopen 151669.)


-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe! <http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

Reply to: