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

[Josip Rodin <joy@gkvk.hr>]

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 :)

> >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.

-- 
     2. That which causes joy or happiness.