This is a feature request to use the "alternatives" set up for the vim commands that can be supplied by the different "flavors" of the vim package. Right now there are 3 flavors of vim, which are built from the same sources with different options specified: - vim-minimal: Small version without GUI. - vim-enhanced: Huge version without GUI. - vim-X11: Huge version with GTK2 GUI. Even though all of the flavors can recognize the different invocations (such as "vi", "view" for read only, "rvi" for restricted and "ex" for ex mode) and act appropriately, the current set up in Fedora points different commands to different flavors of vim. For instance, the "view" and "ex" commands always use the vim-minimal binary. (As a side effect, using "view" to inspect files effectively disables syntax highlighting which is not supported in that version.) The "vim" command is only available in vim-enhanced and not in vim-minimal. Consequently, with only vim-minimal installed, calling "vim" will result in a command not found error. The "vi" command is handled through a shell alias which is by default only applied if the uid is larger than 200, which is quite an obsolete concept these days. The alias makes it so that calling "vi" from the command line will usually bring the featured one from vim-enhanced, but commands that shell out to "vi" (such as "git commit" or "cron" or even "sudo -e" etc.) will typically spawn the one from vim-minimal which is not as full featured as the one you will typically use if you have vim-enhanced installed. Furthermore, the point of having three flavors of "vim" packages is to reduce the installed and memory footprint but on the other hand having the three of them installed and in use largely defeats that purpose, since if you want to have vim-enhanced and you want a gvim around, you still need the three packages installed, since otherwise commands such as "view" and in some cases "vi" will not work. There's also memory usage impact since if you have a copy of "view", a copy of "vim" and a copy of "gvim" started then you'll need to page in the three binaries instead of having a single copy of the binary in memory which can fulfill all three functions... The proposal is to use the "alternatives" system to implement switching between vim flavors as more than one gets installed. The "alternatives" system is clearly suited for this purpose, since even the update-alternatives(8) man page uses "vi" as a clear example of its usage. The "alternatives" system can be used to maintain the /usr/bin/{vim,vi,view,rvim,rvi,rview,ex} symlinks and point them to either "vim.minimal" or "vim.enhanced" or "vim.X11". (Additionally, it could be used to take care of "vimdiff" and "gvim" though these are sometimes only available in one or two of the most featured versions.) The packages would use their %post scripts to register their binaries in the "alternatives" system with a certain priority so that by default the most featured version will be used and still provide a way for an administrator to override the choice by calling "alternatives --set" themselves. This would actually make it possible to have a system where only vim-X11 is installed without vim-minimal and vim-enhanced and still be able to provide "vim" and "vi" and "view" and "ex" commands (since the "vim.X11" binary, assuming we have one, supports checking the name used to call it and not initialize X11 if it is a name that implies non-X11 usage.) Other distributions use a similar setup. For instance, Ubuntu offers three binaries ("vim.tiny", "vim.basic" and "vim.gnome") which are very similar to the 3 flavors offered in Fedora. They use the "alternatives" system to switch between flavors and to ensure the most featured one will be automatically picked when more than one of the packages is installed. I'd be happy to contribute patches to implement this, but I am starting with this feature request Bugzilla entry in order to start some discussion on the subject and to ensure there is interest in such a feature and some commitment to push it forward in case patches are available. Thanks! Filipe
If you work on a patch, don't use alternatives; use environment modules instead. Choice of what "vim" should invoke is a per-user choice rather than a per-system choice.
Toshio: I don't really think modules are appropriate here since essentially we're talking about 3 builds of the exact same software which work (almost) exactly the same. For instance, if you build vim-X11 and call it "vim" it won't start a GUI but will work exactly like the the "vim" from vim-enhanced, it will only behave differently when called "gvim". There are some differences between "vi" from vim-minimal and "vi" (through the alias) from vim-enhanced, mainly because the former has features such as syntax highlighting disabled at build time. But I'd argue that's not a reason two users of the same system to prefer one over the other, after all both are still available (depending on which binaries you call) and if you have a more featured one it's not likely that you will really want to use the more bare one... I think alternatives is really a great fit for this and it actually enables building a more minimal system by only keeping a single vim package instead of three in case you actually need the GUI one, right now you need to still keep the others around, with alternatives you could keep a single one installed... In general, does this proposal make sense? I started looking at making it happen, it's quite tricky because it's hard to get RPM to replace the files with symlinks, I think a solution is possible (probably using triggers), I can invest more time in trying to make it work, but I'd like to have some feedback of whether you agree with this approach before I keep digging on it. Thanks! Filipe
Ping?
Karsten: Ping? Is there interest in getting this done? I think it can be done, though I'm not sure that the only way to have upgrades still working wouldn't be renaming the packages and having Provides: to keep compatibility with the old names... Not sure if that's acceptable. Cheers, Filipe
Give me a few more days, I have some other stuff to finish first.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
(In reply to Filipe Brandenburger from comment #4) > Is there interest in getting this done? User opinion: Yes. I think it's definitely the right thing to do.
Hi Karsten, Any chance we can revisit this one in time to make it to Fedora 23? (Looks like it will be branched from Rawhide on July 14, so that means we need to figure it out before then, right?) Last time I looked, the main problem was replacing a /usr/bin/vim binary owned by a package such as "vim-enhanced" by a symlink managed by the "alternatives" system, particularly on package upgrade... Even using %post hooks, the new version of vim-enhanced gets fully installed before the old version gets removed, and on removal of the old one the symlinks created by alternatives are removed as the old vim-enhanced thinks it owns /usr/bin/vim which is now the symlink... Not really sure if there's a good way around it. Any suggestions? I'd be happy to send a patch, but I'd like to know whether you'd be willing to accept it and your advice on how you think this should be done to work in package upgrades. Thanks! Filipe
Actually I'm more in favor of dropping vim-enhanced as almost everything pulls in X/gdk these days and vimx or a link from gvim to vim are really quite similar to the vim from vim-enhanced. We need to keep vim-minimal for really minimal installs that won't pull in python/perl/X11. It also is really useful in rescue environments, that would be difficult to do with /usr/bin/vi handled by symlink/alternatives.
Can we revisit this. At-least for vim-X11 and vim-enhanced.