Re: Advice for directory to symlink transition
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
Reply to: