> 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! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
