Control: forcemerge 406715 -1 Hi!
On Tue, 2014-03-18 at 18:50:41 +0100, Michael Vogt wrote: > On Tue, Mar 18, 2014 at 03:33:35PM +0100, Guillem Jover wrote: > > This is “expected” behaviour, I documented it in the dpkg FAQ because it > > seems to trip people over. The Debian policy also documents this (§6.6.4). > > > > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Will_dpkg_replace_a_symlink_with_a_directory_or_vice_versa.3F> > > > > Given the above, I'll be closing this report if there's no other > > issues besides this one. > Thanks for your reply and the link to the FAQ and sorry for this > unneeded bugreport. I should have been move careful in my > research. Feel free to close the report. No problem. Merging it now with previous incarnations of this. > Given that this behavior is not that (that) intuitive I wonder if dpkg > could issue a warning during unpack? Maybe something like the attached > patch? I'm happy to improve the warning message and add one for the > other way around (dir is replaced with symlink). The problem is that this has been the intended behaviour for dpkg all along, mainly to support local admins switching directories to symlinks and the reverse to be able to rearrange filesystems and disks w/o needing whole reinstalls and similar. So starting to issue warnings would be quite annoying in those cases. The issue here is that dpkg does not have enough information to distinguish if the discrepancy is due to a switch in the packaging or due to sysadmin actions. > Could you elaborate a little bit what the FAQ means with metadata > tracking? Would the $pkg.lists file need to be amended with > information like: > /path/to/dir =d > /path/to/file =f > /path/to/symlink =s > ? More or less, in addition to file size, uid/gid, mode, symlink target, device IDs, etc. Reusing the .list files is probably not a good idea though, because unfortunately other programs try to use those internal files and they might silently break then. And if those are to disappear, then I might as well try to store the data in a way that makes it faster to load, as .list files are the currently slowest part of dpkg startup, in many situations. My current thinking is to use a new mtree(5) formatted file to track those and also the file checksums. I think I might have the beginning of some code for that somewhere, but I'm not sure. In any case, I still need to consider how to internally handle shared paths with different metadata, like directories or ref-counted paths in M-A:same packages, and metadata switched for those shared paths, for example. Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
