Hi,
I assume it is because the _core directory is new in NumPy 2, so dpkg can just create the symlinks at unpack time. The latter two directories need to be transitioned from a real directory in NumPy 1 to a symlink during the package upgrade. Apparently this step fails, leaving an empty directory instead.
The way I understood it, dpkg does not track the type of files, only ownership. Multiple owners are permitted, if multiple packages contain the same path -- conflicts are checked and resolved only at unpack time.
So what happens is that the symlink is unpacked, and the resolution rule decides in favour of the directory, but the new package also shares in the ownership of this path, so it is never removed.
Guillem is working on a branch of dpkg that tracks types and other metadata as well, which would probably detect and report this as a file conflict. Not sure if the "directory wins against symlink without causing an error" resolution rule would remain here.
I think this can be fixed only with a Conflicts to make sure packages that provide the old path as a directory are removed or upgraded before the package providing the symlink is unpacked.
I *think* (but I haven't tested it) that if the package unpacking the symlink is also the last remaining owner of the directory and the directory is empty, then the unpack should succeed and the symlink installed.
The question is, how do I fix this? I could add some code to postinst to check if there is an empty directory where a symlink should be. Is this a reasonable approach?
I think the preinst is a better place -- it is sequenced closer to unpacking, and it has a chance of aborting the unpack if the directory is not empty (so you still need the Conflicts against the older packages).
Simon
