> > > grappa:~# debsums --changed > > > /usr/share/doc/libtiff-tools/README > > > /usr/share/doc/libtiff-tools/TODO > > > /usr/share/doc/libtiff-tools/changelog.Debian.gz > > > /usr/share/doc/libtiff-tools/changelog.gz > > > > This one seems clearish, a previous version of libtiff-tools used to > > symlink /usr/share/doc/libtiff-tools to /usr/share/doc/libtiff4. Also > > the maintainer script removes the /usr/share/doc/libtiff-tools on > > upgrade if it's a directory and not symlink, which makes those > > disappear only on upgrade not on a clean installation. > > This certainly needs to be fixed.
Wow. All this stuff happened so long ago that I didn't even remember ever having done this. It seems like I added this preinst at some time when switching from directories to symlinks, and at some later time, probably decided that was a bad idea and switched back to directories without remembering about the preinst. Or maybe the package was using symlinks when I originally inherited it. I can dig through my svn logs and figure out what's going on. It seems to me that the current behavior is that all the tiff binary packages have real directories in /usr/share/doc. In this case, the mostly right thing for the preinst to do is to unconditionally delete /usr/share/doc/PKG if it is a symlink. If someone is upgrading from a version before it was ever a symlink to a current version, everything is fine, and if someone is upgrading from a version that was a symlink, it should still be fine. Does that sound right? This bug will likely affect the tiff3 source package as well. If it does, I will duplicate the bug and assign it there too. The thing I find strangest about this is that there is nothing in the changelog for the tiff packages indicating about changing back and forth between these things being symlinks and directories. I'm really surprised that I wouldn't have mentioned something that in the changelog. Well, I have svn logs going back to when I first took over this package, so I'm sure I'll be able to sort it out. I'll double check all the assumptions I made above in case I'm doing something different from what I think I'm doing. (I should probably run fsck on my brain just to be safe.) -- Jay Berkenbilt <q...@debian.org> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org