Bug#337332: vim.list unpacks two wrong links (which update-alternatives then corrects)

[jeremy at jsbygott.fsnet.co.uk]

> > Well, /usr/share/man/man1/eview.1.gz on your list looks slightly strange

> It is just a manpage link

Sure, but I expected to see a matching link for /usr/bin/eview as well.
Or (if the binary link is done with update-alternatives) no explicit
manpage link either (making it as a slave link). This looks untypical,
hence my comment.

Sometimes cosmetic issues become practical in the future.  Eg someone
rewrites update-alternatives so your scheme fails, or someone wants to
auto-search the whole archive for bad packaging, or someone ports debian
to a new architecture that prohibits dangling links.  Yes, I have
paranoid imagination. :-)

Okay, less crazy, have you tested upgrades from old vim?  I can imagine
dpkg unpacking various things including those links, but then some old
prerm or postrm trashing what has been unpacked?  I just don't like
depending on undocumented or difficult-to-predict behaviour.

But in principle, I agree with all your reasoning; thanks for taking the
time to explain.  And avoiding orrible conflicts between variants is
nice.

[I suppose you could have had a whole extra package instead:

vim-standard -> standard vim variant
vim-*        -> other variants
vim          -> almost empty, creates the symlinks
                depends on ( vim-standard | vim-variant1 | ... )

No, I do not advocate this.]