Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 69852 - app-editors/vim and app-editors/nvi have conflicting files
Summary: app-editors/vim and app-editors/nvi have conflicting files
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Vim Maintainers
Depends on:
Reported: 2004-11-02 09:28 UTC by Alexander Skwar
Modified: 2005-02-25 01:27 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

Ebuild changed to install nvi as nvi instead of vi (nvi-1.81.5-r3.ebuild,1.13 KB, text/plain)
2005-02-18 07:48 UTC, Karl Hakimian
Ebuild changed to stop block with nvi (vim-6.3-r5.ebuild,832 bytes, text/plain)
2005-02-18 07:52 UTC, Karl Hakimian
Change vim.eclass to install links with v prefix (vimpatch,1.41 KB, patch)
2005-02-18 07:53 UTC, Karl Hakimian
Details | Diff
Script to make vi the best available vi (vi,131 bytes, text/plain)
2005-02-18 12:44 UTC, Karl Hakimian
Patch against nvi-1.81.5-r2.ebuild to install binaries as n{vi,ex,view} and use alternatives.eclass to manage symlinks (bug69852-nvi-1.81.5-r2.ebuild-alternatives.patch,1.10 KB, patch)
2005-02-18 16:13 UTC, Sascha Silbe
Details | Diff
Patch against vim.eclass to use alternatives.eclass to manage symlinks (bug69852-vim.eclass-alternatives.patch,1.70 KB, patch)
2005-02-18 16:14 UTC, Sascha Silbe
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Skwar 2004-11-02 09:28:36 UTC
making executable: /usr/lib/
>>> Completed installing into /var/tmp/portage/nvi-1.81.5-r2/image/

* checking 28 files for package collisions
existing file /usr/bin/ex is not owned by this package
existing file /usr/bin/vi is not owned by this package
existing file /usr/bin/view is not owned by this package
existing file /usr/share/man/man1/ex.1.gz is not owned by this package
existing file /usr/share/man/man1/view.1.gz is not owned by this package
* spend 0.103163003922 seconds checking for file collisions
* This package is blocked because it wants to overwrite
* files belonging to other packages (see messages above).
* If you have no clue what this is all about report it
* as a bug for this package on

package app-editors/nvi-1.81.5-r2 NOT merged

No package files given... Grabbing a set.
[14:23:25 alexander@server:/Downloads/ISO-Images/ToDo/Knoppix] $ epm -qf /usr/bin/vi
file /usr/bin/vi is not owned by any package
[18:06:02 alexander@server:/Downloads/ISO-Images/ToDo/Knoppix] $ ls -la /usr/bin/vi
lrwxrwxrwx  1 root root 3 25. Jul 10:49 /usr/bin/vi -> vim
[18:23:09 alexander@server:/Downloads/ISO-Images/ToDo/Knoppix] $ epm -qf /usr/bin/vim
[18:23:37 alexander@server:/Downloads/ISO-Images/ToDo/Knoppix] $ ls -lad /var/db/pkg/*/*vim*
drwxr-xr-x  2 root root 4096 16. Okt 13:59 /var/db/pkg/app-editors/gvim-6.3-r1
drwxr-xr-x  2 root root 4096 12. Sep 15:58 /var/db/pkg/app-editors/vim-6.3-r1
drwxr-xr-x  2 root root 4096 12. Sep 15:51 /var/db/pkg/app-editors/vim-core-6.3-r2

Reproducible: Always
Steps to Reproduce:
1. Add colision-protect to FEATURES
2. emerge vim
3. emerge vi

Actual Results:  
Error message as shown above.

Expected Results:  
Both packages should be installable at the same time. One way might be to use
something like update-alternatives from Debian.

[00:41:05 alexander@server:~/Programme/src/mozilla] $ emerge info Portage
2.0.51-r2 (default-x86-2004.2, gcc-3.4.2, glibc-,
2.6.9-ck2ASN2004103001 i686)
System uname: 2.6.9-ck2ASN2004103001 i686 AMD Athlon(tm) XP 2000+
Gentoo Base System version 1.6.4
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-
Headers:  sys-kernel/linux26-headers-
Libtools: sys-devel/libtool-1.5.2-r5
CFLAGS="-O2 -march=athlon-xp -pipe"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe"
FEATURES="autoaddcvs ccache collision-protect distlocks sandbox"
USE="3dnow 3dnowex X aalib acl alsa apache2 apm arts artswrappersuid async avi
bluetooth bzlib cairo calendar cddb cdparanoia cdr cdrom codecs crypt cscope
cups curl curlwrappers dga diet directfb divx4linux djbfft encode esd ethereal
evo exif fam fbcon fbdev ffmpeg fftw flac flash foomaticdb foreign-package
foreign-sysvinit ftp fwdzone gd gdbm gif gimp gimpprint gnokii gnome gphoto2 gpm
gstreamer gtk gtk2 guile hal iconv imagemagick imap imlib immqt-bc java
javascript jpeg kde libedit libg++ libwww lzo lzw lzw-tiff mad maildir
mailwrapper matroska matrox mbox mmap mmx mng mozilla mpeg ncurses network nls
noantlr nobcel nobeanutils nobsh nocommonslogging nocommonsnet nojdepend nojsch
nojython nolog4j nooro noregexp norhino noxalan noxerces nptl offensive ofx
oggvorbis opengl oss pam parse-clocks pcntl pcre pdflib perl pic pie png posix
ppds python qt quicktime quotes readline recode samba sasl sdl shared slang
sockets spell sse ssl svg sysvipc tcltk tcpd tetex theora tiff truetype unicode
usb videos vim-with-x wmf x86 xchattext xfs xml2 xmms xv xvid zlib
video_cards_matrox linguas_de"
Comment 1 Ciaran McCreesh 2004-11-04 07:56:35 UTC
Yeah, it's kinda icky. All the vi clones are trying to provide the same files. I'm looking for a standardised way of handling this, see the discussion on the gentoo-dev list.
Comment 2 Sascha Silbe 2005-02-09 02:01:00 UTC
For a start, app-editors/nvi should install as nvi instead of vi and app-editors/vi as tvi (traditional vi). Until a better solution is found, create a link /bin/vi (vi really should be on the root partition, so it can be used to repair fstab) in pkg_postinst to the currently-emerging-vi-clone if it does not yet exist. If the user wants to switch the default vi, (s)he can do so by just changing the SymLink. As it's created in postinst and not recorded in Portage, it will not affect collision-protect.  IMO "vi" should behave as much as traditional vi as possible (i.e. prefer app-editors/vi over app-editors/nvi and that one over app-editors/vim); if you want to get a specific clone, call it directly. Otherwise working on several platforms with different clones of vi installed will give you headaches (especially for the vi:=vim case). Or at least, I'm getting headaches from it.  
Comment 3 Christoph Probst 2005-02-09 11:20:54 UTC
Any solutions yet?

Even if every vi-clone creates the file /usr/bin/vi, there should be at least a program file for each individual file e.g.


As far as I can see this is the case for vim but not for nvi.
Comment 4 Ciaran McCreesh 2005-02-09 11:25:20 UTC
Ok, original vi is no longer in the tree, so we're left with a collision between nvi and vim. If no-one comes up with a decent solution to the rest I'm just going to introduce a block.
Comment 5 Sascha Silbe 2005-02-09 13:56:26 UTC
A block would be exactly the opposite of what we need. We often have users with different preferences (nvi vs. vim) on the same host.
What's the problem with the short-time solution I proposed?
Another option: Don't create /bin/vi at all, let the user type nvi or vim according to his taste.
Comment 6 Ciaran McCreesh 2005-02-09 14:04:42 UTC
Upstream install nvi as 'vi', therefore we install it as 'vi'. Vim is installed as 'vim', but we generate 'vi' symlinks for it because POSIX expects vi to exist. Creating a vi-symlinks eclass just to handle this is serious overkill, and creating a full-blown alternatives setup isn't something I have time for right now.

As for preference, if we *did* have an alternatives setup we'd go for vim over anything else since vim is very close to POSIX compliant whereas the rest aren't.
Comment 7 Sascha Silbe 2005-02-09 14:13:36 UTC
You don't need a new eclass for that. Just creating the link in postinst if it doesn't exist is sufficient. That's a one-liner.
Comment 8 Ciaran McCreesh 2005-02-09 14:22:26 UTC
...except that we have to handle unmerges, and handle one being merged then another then one being unmerged and so on, and we have to do it across multiple packages.
Comment 9 Alexander Skwar 2005-02-09 21:49:56 UTC
Well, I still think, that it would be a *VERY* good idea to introduce something very much like the "update-alternatives" from Debian to Gentoo. It handles all theses problems pretty well.
Comment 10 Ciaran McCreesh 2005-02-10 07:03:52 UTC
Added blocks.
Comment 11 Alexander Skwar 2005-02-10 07:43:08 UTC
Fixed? How?

You added blocks, which is, just as Sascha said, the opposite of what's needed. I'd also be interested on why you don't comment on the Debian update-alternatives approach.
Comment 12 Ciaran McCreesh 2005-02-10 07:49:44 UTC
I did comment on the alternatives approach. See comment #1. It's a possibility for sometime in the future if such a system is ever created. However, since the requirements list for doing this properly is rather lengthy, it's not going to happen overnight.
Comment 13 Sascha Silbe 2005-02-10 08:42:56 UTC
That's exactly why we need a proper short-time solution.
You've just broken exactly those systems (nvi and vim installed in parallel) that were the only ones having the problem you tried to fix. Other systems won't ever have this issue, since /usr/bin/vi will be owned by exactly one package.
As a first measure, PLEASE remove the block. It's better to have vim overwrite nvi (this will only happen for systems where both are installed in parallel, no harm done to any other system), thus needing to re-emerge nvi after an vim update, than not having the possibility of installing both in parallel at all.
Comment 14 Ciaran McCreesh 2005-02-10 08:51:17 UTC
No, the problem is that if you try to emerge both nvi and vim, you'll get a nasty failure if you have collision protection enabled. So, the solution is to mark the packages as mutually exclusive since they install the same files, which isn't allowed.

I *was* just going to leave this bug until we had some kind of alternatives system in place, but now that traditional vi is gone we're left with a two-way block, which isn't as messy to put in RDEPEND.
Comment 15 Christoph Probst 2005-02-10 10:17:46 UTC
My system is used by many different people. Some prefere vim and some a more traditional vi like nvi. The only problem I had was, that nvi wouldn't install itself under nvi.

I don't care which program owns the symlink /usr/bin/vi and I'm happy to create it myself if only both programs create their native program file under /usr/bin/vim and /usr/bin/nvi.

A block doesn't solve anything and makes things just more difficult for me and everyone else who wants both version.
Comment 16 Ciaran McCreesh 2005-02-10 11:19:41 UTC
The block *does* solve the main issue, which was that two incompatible packages weren't marked as mutually exclusive. If you want both, I suggest you put together a GLEP and a sample implementation of an alternatives system for Gentoo.
Comment 17 Alexander Skwar 2005-02-10 14:25:52 UTC
Sorry, but no, the main issue was not what you stated. The main issue (or rather the expected result) was:

Both packages should be installable at the same time.

*This* issue hasn't been solved. You solved a different issue :)
Comment 18 Karl Hakimian 2005-02-11 06:04:42 UTC
I'm sure I'm not the only person who has a requirement for both editors being installed. Making them block is a very bad thing for me. Can we try something else?
Comment 19 Karl Hakimian 2005-02-11 07:06:12 UTC
I've been giving this a bit of thought. Is there any reason we are not installing the various versions of vi with names like nvi, nex ... vim, mex, ... and then using a use flag (something like primary or anything better you can think of) on the package we want installed as vi, ex, ...?

Since Gentoo is all about choice, I hate to see our choices limited when there is no real good reason to do it.

Comment 20 Ciaran McCreesh 2005-02-11 07:12:44 UTC
We're using upstream names for installing. If we had an alternatives system, I'd install them with the prefix, but we don't.
Comment 21 Karl Hakimian 2005-02-13 08:40:43 UTC
I did not think nvi even had an install. They only recently got a configure and I didn't think it did all that much.

When I have built ebuilds for special needs for myself, I have simply renamed the executable after it compiles and then install it. It's a one liner in the ebuild. While I can easily do this myself, I think there are probably more people needing both installed than just me.
Comment 22 Sascha Silbe 2005-02-13 09:40:48 UTC
Renaming the nvi executables is quite easy: pass "--program-prefix=n" to configure.
Comment 23 Karl Hakimian 2005-02-18 05:40:20 UTC
Not to be too pushy, but since there seems to be reasonable solutions that will allow both nvi and vim to coexist, is it possible to have that done? Would you like me to provide a patch for the ebuild?

Should I open a new bug?
Comment 24 Ciaran McCreesh 2005-02-18 05:52:06 UTC
If you really do have an elegant way of making this work which addresses the issues in comment #8, by all means reopen and attach a patch.
Comment 25 Karl Hakimian 2005-02-18 07:48:46 UTC
Created attachment 51522 [details]
Ebuild changed to install nvi as nvi instead of vi

Modified nvi ebuild to resolve conflict between nvi and vim
Comment 26 Karl Hakimian 2005-02-18 07:52:01 UTC
Created attachment 51523 [details]
Ebuild changed to stop block with nvi

All I changed here was to remove the block. The changes were made to the
Comment 27 Karl Hakimian 2005-02-18 07:53:31 UTC
Created attachment 51524 [details, diff]
Change vim.eclass to install links with v prefix

The install section of the eclass simple links in ex and view. This patch will
change those to vex and vview.
Comment 28 Karl Hakimian 2005-02-18 07:53:52 UTC
The nvi changes are very straight forward. I have attached a new ebuild just adding the suggested prefix.

I do not feel any where near as confident with eclasses as I do with the ebuilds themselves, so feel free to change my approach to the vim problem. I have attached a patch to vim.eclass and an ebuild for vim.

Since these ebuilds will install their packages with different names, there is no loger a conflict. A user can link whichever one to vi, ex, and view.
Comment 29 Ciaran McCreesh 2005-02-18 07:56:33 UTC
No good. We always need a sane /usr/bin/vi whenever we have anything vi-like installed.
Comment 30 Karl Hakimian 2005-02-18 09:19:37 UTC
I have some ideas I will try out, but why not just display a message in the ebuild that tells you to ln /usr/bin/yourfavoritevi /usr/bin/vi?
Comment 31 Karl Hakimian 2005-02-18 09:38:48 UTC
OK. First a question. Where is it written that any vi like editor needs to show up as /usr/bin/vi?

Now a suggestion, let me know if you need me to provide a patch.

create a defaultvi use flag. If the use flag is present, have the vi add a link to itself as /usr/bin/vi and have the ebuild provide virtual/vi or something like that. Also, have it block on virtual/vi so if another ebuild has that use flag set it will block.
Comment 32 Ciaran McCreesh 2005-02-18 09:48:53 UTC
Making the user do the links is daft, and the 'defaultvi' USE flag is far too ugly a hack to be considered.

As for the name, try POSIX.
Comment 33 Karl Hakimian 2005-02-18 09:56:51 UTC
I have not read the POSIX documents on what they have to say about vi. Does it state that ANY vi has to be named vi? If so, pick one and call it vi. We already have an ebuild for vi that installs as /usr/bin/vi. If you want vi, you can get it. Nvi showing up as vi was OK by me since it was the BSD replacement for vi. All other vi like things are not vi and are usually installed with whatever name they have.

This seems like a pretty arbitrary requirement that is resulting in a significant lack of choice. I have offered a couple of solutions that will solve the problem and allow us to maintain a high level of choice on our gentoo systems. How about we pick one and use it until a better idea comes along?

I really don't want to have to maintain my own ebuilds just because a working solution is considered too ugly.
Comment 34 Ciaran McCreesh 2005-02-18 10:06:51 UTC
There hasn't been a viable solution posted to this bug yet. I was happy leaving everything as-is until we got an alternatives system set up, but it seems that the file conflicts are making people unhappy, hence the block. I'm not going to go with some nasty hack here, it has to be done properly. Anything involving USE flags, users doing the symlinks, using weird names or not having 'vi' point to something isn't an option.
Comment 35 Karl Hakimian 2005-02-18 10:10:48 UTC
I'm reading your answer as anything involving the currently available methods for resolving this problem will simply not be accepted. Seems kind of arbitrary. Is there any schedule for getting an alternatives system?
Comment 36 Ciaran McCreesh 2005-02-18 10:27:15 UTC
It's not arbitrary at all. If you want a more detailed explanation:

* Using a USE flag to control a single symlink is massive overkill. It also can't be set globally for obvious reasons, which leaves us with no /usr/bin/vi by default.

* Telling the user to symlink things defeats the entire point of having a package manager. And, chances are, most users won't, which leaves us with no /usr/bin/vi.

* Using non-upstream names without good reason is a policy violation. If we *do* do this, there needs to be some way of sticking in sane symlinks automatically such that the familiar names will work.

* We need a 'vi' binary or link, because a) it is expected, and b) POSIX requires 'vi' on all interactive systems

As for a proper alternatives system, there are vague plans but due to a lack of coder time and the large number of requirements that such a system would have were it to be done properly, they've not gotten very far.
Comment 37 Karl Hakimian 2005-02-18 10:41:28 UTC
OK. I'll make one more suggestion and then I will go away and do my own thing. (Though I won't promise to be quite ;-) )

Since POSIX requires vi, put one in the base system (have an interactive use flag if need be that is set by default in the profile) otherwise we are clearly not caring about being all that POSIX compliant. I really don't care which one is chosen, I can deal with it. 
Comment 38 Ciaran McCreesh 2005-02-18 10:48:43 UTC
I've been trying to get the default virtual/editor changed to vim for years. Not gonna happen, though, so we'll have to just settle for giving the user the POSIX-specified editor whenever they emerge any of the vi clones.
Comment 39 Karl Hakimian 2005-02-18 10:55:03 UTC
Glad I didn't promise to be quite. :-) Now I'm back to seeing this a pretty arbitrary. We clearly don't care about being all that POSIX compliant (no vi in the default system) but as soon as someone chooses a vi, gosh darn it, they are going to get it with POSIX compliance. Even if it means we limit their choice to one and only one vi like editor.

So which is it that is important? POSIX compliance? Or giving Gentoo users control over how they install their systems?
Comment 40 Ciaran McCreesh 2005-02-18 10:58:24 UTC
Ok, this bug clearly isn't going anywhere, and I don't have time to play with the trolls. Please file a new bug when we have an alternatives system implemented.
Comment 41 Karl Hakimian 2005-02-18 12:44:35 UTC
Created attachment 51545 [details]
Script to make vi the best available vi

Here's an idea that might meet the specified criteria.

Install vim as vim, nvi as nvi and add the attached script to the
/etc/profile.d directory or where ever we do that sort of thing. The script
will produce an alias for vi to one of the ones available.

If aliases are bad, we can try to get a similar script added to the baselayout
that select a vi or prints a message instructing the user to emerge one. This
latter approach has the additional advantage of increasing POSIX compliance.
Comment 42 Sascha Silbe 2005-02-18 16:13:56 UTC
Created attachment 51555 [details, diff]
Patch against nvi-1.81.5-r2.ebuild to install binaries as n{vi,ex,view} and use alternatives.eclass to manage symlinks
Comment 43 Sascha Silbe 2005-02-18 16:14:48 UTC
Created attachment 51556 [details, diff]
Patch against vim.eclass to use alternatives.eclass to manage symlinks
Comment 44 Sascha Silbe 2005-02-18 16:25:19 UTC
Please don't insult us by calling us trolls. We're not arguing to annoy you, but because we've got real multi-user systems where we need to provide both nvi and vim to the users.
Of course we could just install nvi and vim manually (such solving the problem for ourselves), but what's the use of a distribution then? We'd need to closely watch nvi and vim announces and BugTraq and all those channels; wasting energy better spent otherwise.

While we agree with you on the long-term solution (some kind of Debian-like update-alternatives system) and might even help you with that (as time permits, that is :( ), we also need a short-term solution.
So please accept this one and let us spend our energy together in providing a good long-term solution, instead of wasting it with arguing and providing yet-another-possible-short-term-solution.

BTW: What exactly is the state of your proposed update-alternatives system? The only thing I've seen so far was the discussion on gentoo-dev some months ago. Has anyone already started writing a GLEP or a prototype?