Bugzilla Bug 69852

making executable: /usr/lib/libvi.so.0.0.0
>>> 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 http://bugs.gentoo.org

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
vim-6.3-r1
[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.3.4.20041021-r0,
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-2.15.92.0.2-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon-xp -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER=""
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"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache collision-protect distlocks sandbox"
GENTOO_MIRRORS="http://localhost/~alexander/gentoo-files/
http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/
ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo
ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://194.117.158.29"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
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"

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.

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.  

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.

/usr/bin/vim
/usr/bin/nvi
...

As far as I can see this is the case for vim but not for nvi.

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.

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.

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.

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.

...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.

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.

Added blocks.

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.

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.

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.

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.

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.

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.

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 :)

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?

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.

We're using upstream names for installing. If we had an alternatives system,
I'd install them with the prefix, but we don't.

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.

Renaming the nvi executables is quite easy: pass "--program-prefix=n" to
configure.

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?

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.

Created an attachment (id=51522) [details]
Ebuild changed to install nvi as nvi instead of vi

Modified nvi ebuild to resolve conflict between nvi and vim

Created an attachment (id=51523) [details]
Ebuild changed to stop block with nvi

All I changed here was to remove the block. The changes were made to the
eclass.

Created an attachment (id=51524) [details]
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.

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.

No good. We always need a sane /usr/bin/vi whenever we have anything vi-like
installed.

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?

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.

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.

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.

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.

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?

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.

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. 

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.

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?

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.

Created an attachment (id=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.

Created an attachment (id=51555) [details]
Patch against nvi-1.81.5-r2.ebuild to install binaries as n{vi,ex,view} and use
alternatives.eclass to manage symlinks

Created an attachment (id=51556) [details]
Patch against vim.eclass to use alternatives.eclass to manage symlinks

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?