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

Reply via email to