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

[jeremy at jsbygott.fsnet.co.uk]

> I attach to this mail the current vim-common.list (those
> alternatives used to be installed by vim, but are now installed by
> vim-common). Have a look at it.

Well, /usr/share/man/man1/eview.1.gz on your list looks slightly
strange, but I would need to see the maintainer scripts.

>From what you say, the vim-packages have changed a lot even since the
last upload (1:6.4-001+2).  *Your* vim-common.list looks much more
like vim.list from stable/testing/unstable than like vim-common.list,
eg

http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=vim-common&version=unstable&arch=all

So now I have only questions:

Is vim-common in future going to be architecture-dependent?  Some
files, eg /usr/bin/xxd, look architecture-dependent.

Is vim-common going to install dangling links and /etc/alternatives/* for
binaries that aren't in vim-common? Is that elegant? Is it going to be
popular?  Is someone going to say it breaches at least the intention
of policy? Policy vn 3.6.1, appendix F: 

    Each package provides its own version under its own name, and
    calls update-alternatives in its postinst to register its version
    (and again in its prerm to deregister it).

Given all the changes, I think my original question has disappeared,
so I am happy if you mark this bug wontfix and work on something
better!