On Sat, Aug 09, 2008 at 11:36:49PM -0300, Nelson A. de Oliveira wrote: > Hi! > > On Sat, Aug 9, 2008 at 10:49 PM, James Vega <[EMAIL PROTECTED]> wrote: > > Make sure there are no /usr/share/vim/vim71 or /usr/share/vim/vim72* > > directories remaining. > > I won't do this now because I think that the problem is there. > Without any vim* packages installed, I still have this: > > $ ls -l /usr/share/vim/vim71/doc > total 276 > -rw-r--r-- 1 root root 8010 Mai 4 16:39 help.txt > -rw-r--r-- 1 root root 268893 Mai 4 16:39 tags > > They are supposed to be from some vim* package, right? But they aren't > (at least on my system).
On a fresh system, they are provided by vim-tiny and (up until 7.1.314-1) vim-runtime Replaced them. Those files are from the vim-runtime package as the ones provided in vim-tiny are smaller. In 7.1.314-1, I changed the packaging so those files were handled by diversions instead of having vim-runtime Replace vim-tiny. This was done because I had naïvely overlooked the scenario that someone may uninstall vim-runtime but leave vim-tiny installed, in which case they would have no help files. Using diversions addresses this because when vim-runtime is removed, vim-tiny's help.txt and tags are no longer being diverted by vim-runtime's and become available again. It looks like you still have the help.txt and tags from vim-runtime_7.1.293-3, which is what I was using as a starting point when trying to reproduce this bug. The initial versions of the diversion handling that was in Vim's maintainer scripts was a bit more clever (fragile? ;) than it needed to be since dpkg-divert didn't properly handle diversions in yet-to-be created directories. One thing I toyed with (but didn't actually include in a released package), was to remove the help.txt/tags files if diversions were being setup for the first time. The comment I had at the time was that this was needed to make sure the proper files were diverted. I'll take another look at the bug and make sure to start at a version pre-7.1.314-1 and upgrade a package at a time. Although, if this is a problem that only occurs by tracking unstable and not by tracking testing, I may close the bug. I did a number of relatively quick uploads to sort out the diversion code, so if the broken package wasn't available for long, manually cleaning up the mess for the few people that were affected is safer than overcomplicating maintainer scripts for something that isn't wide-spread. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
