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:
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
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
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.
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 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?
Arguably it could go check, but I guess there's a reason against that if
nobody did that yet.
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.
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.)
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!