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 attachment 51522 [details] Ebuild changed to install nvi as nvi instead of vi Modified nvi ebuild to resolve conflict between nvi and vim
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 eclass.
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.
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 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.
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
Created attachment 51556 [details, diff] 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?