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