69852 2004-11-02 09:28 0000 app-editors/vim and app-editors/nvi have conflicting files 2005-02-25 01:27:52 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux CLOSED FIXED P2 normal --- 1 askwar@digitalprojects.com vim@gentoo.org chris-ml-gentoo-bugzilla@netzpunkt.org sascha-gentoo-bugzilla@silbe.org t4y68ds02@sneakemail.com usata@gentoo.org askwar@digitalprojects.com 2004-11-02 09:28:36 0000 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" ciaran.mccreesh@googlemail.com 2004-11-04 07:56:35 0000 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. sascha-gentoo-bugzilla@silbe.org 2005-02-09 02:01:00 0000 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. chris-ml-gentoo-bugzilla@netzpunkt.org 2005-02-09 11:20:54 0000 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. ciaran.mccreesh@googlemail.com 2005-02-09 11:25:20 0000 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. sascha-gentoo-bugzilla@silbe.org 2005-02-09 13:56:26 0000 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. ciaran.mccreesh@googlemail.com 2005-02-09 14:04:42 0000 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. sascha-gentoo-bugzilla@silbe.org 2005-02-09 14:13:36 0000 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. ciaran.mccreesh@googlemail.com 2005-02-09 14:22:26 0000 ...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. askwar@digitalprojects.com 2005-02-09 21:49:56 0000 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. ciaran.mccreesh@googlemail.com 2005-02-10 07:03:52 0000 Added blocks. askwar@digitalprojects.com 2005-02-10 07:43:08 0000 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. ciaran.mccreesh@googlemail.com 2005-02-10 07:49:44 0000 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. sascha-gentoo-bugzilla@silbe.org 2005-02-10 08:42:56 0000 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. ciaran.mccreesh@googlemail.com 2005-02-10 08:51:17 0000 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. chris-ml-gentoo-bugzilla@netzpunkt.org 2005-02-10 10:17:46 0000 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. ciaran.mccreesh@googlemail.com 2005-02-10 11:19:41 0000 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. askwar@digitalprojects.com 2005-02-10 14:25:52 0000 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 :) t4y68ds02@sneakemail.com 2005-02-11 06:04:42 0000 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? t4y68ds02@sneakemail.com 2005-02-11 07:06:12 0000 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. ciaran.mccreesh@googlemail.com 2005-02-11 07:12:44 0000 We're using upstream names for installing. If we had an alternatives system, I'd install them with the prefix, but we don't. t4y68ds02@sneakemail.com 2005-02-13 08:40:43 0000 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. sascha-gentoo-bugzilla@silbe.org 2005-02-13 09:40:48 0000 Renaming the nvi executables is quite easy: pass "--program-prefix=n" to configure. t4y68ds02@sneakemail.com 2005-02-18 05:40:20 0000 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? ciaran.mccreesh@googlemail.com 2005-02-18 05:52:06 0000 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. t4y68ds02@sneakemail.com 2005-02-18 07:48:46 0000 Created an attachment (id=51522) Ebuild changed to install nvi as nvi instead of vi Modified nvi ebuild to resolve conflict between nvi and vim t4y68ds02@sneakemail.com 2005-02-18 07:52:01 0000 Created an attachment (id=51523) Ebuild changed to stop block with nvi All I changed here was to remove the block. The changes were made to the eclass. t4y68ds02@sneakemail.com 2005-02-18 07:53:31 0000 Created an attachment (id=51524) 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. t4y68ds02@sneakemail.com 2005-02-18 07:53:52 0000 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. ciaran.mccreesh@googlemail.com 2005-02-18 07:56:33 0000 No good. We always need a sane /usr/bin/vi whenever we have anything vi-like installed. t4y68ds02@sneakemail.com 2005-02-18 09:19:37 0000 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? t4y68ds02@sneakemail.com 2005-02-18 09:38:48 0000 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. ciaran.mccreesh@googlemail.com 2005-02-18 09:48:53 0000 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. t4y68ds02@sneakemail.com 2005-02-18 09:56:51 0000 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. ciaran.mccreesh@googlemail.com 2005-02-18 10:06:51 0000 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. t4y68ds02@sneakemail.com 2005-02-18 10:10:48 0000 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? ciaran.mccreesh@googlemail.com 2005-02-18 10:27:15 0000 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. t4y68ds02@sneakemail.com 2005-02-18 10:41:28 0000 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. ciaran.mccreesh@googlemail.com 2005-02-18 10:48:43 0000 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. t4y68ds02@sneakemail.com 2005-02-18 10:55:03 0000 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? ciaran.mccreesh@googlemail.com 2005-02-18 10:58:24 0000 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. t4y68ds02@sneakemail.com 2005-02-18 12:44:35 0000 Created an attachment (id=51545) 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. sascha-gentoo-bugzilla@silbe.org 2005-02-18 16:13:56 0000 Created an attachment (id=51555) Patch against nvi-1.81.5-r2.ebuild to install binaries as n{vi,ex,view} and use alternatives.eclass to manage symlinks sascha-gentoo-bugzilla@silbe.org 2005-02-18 16:14:48 0000 Created an attachment (id=51556) Patch against vim.eclass to use alternatives.eclass to manage symlinks sascha-gentoo-bugzilla@silbe.org 2005-02-18 16:25:19 0000 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? 51522 2005-02-18 07:48 0000 Ebuild changed to install nvi as nvi instead of vi nvi-1.81.5-r3.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA1IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L2FwcC1lZGl0b3JzL252aS9udmktMS44MS41LXIy LmVidWlsZCx2IDEuMTAgMjAwNS8wMi8xMCAxNTowMzoyOSBjaWFyYW5tIEV4cCAkCgppbmhlcml0 IGV1dGlscwoKREVTQ1JJUFRJT049IlZpIGNsb25lIgpIT01FUEFHRT0iaHR0cDovL3d3dy5ib3N0 aWMuY29tL3ZpLyIKU1JDX1VSST0iaHR0cDovL3d3dy5rb3RuZXQub3JnL35za2ltby9udmkvZGV2 ZWwvJHtQfS50YXIuZ3oiCgpMSUNFTlNFPSJTbGVlcHljYXQiClNMT1Q9IjAiCktFWVdPUkRTPSJ4 ODYgcHBjIHNwYXJjIH5taXBzIGFscGhhIGhwcGEgYW1kNjQgcHBjNjQiCklVU0U9IiIKCkRFUEVO RD0idmlydHVhbC9saWJjCgk9c3lzLWxpYnMvZGItMy4yKiIKUkRFUEVORD0iJHtERVBFTkR9IgpQ Uk9WSURFPSJ2aXJ0dWFsL2VkaXRvciIKCnNyY191bnBhY2soKSB7Cgl1bnBhY2sgJHtBfQoJY2Qg JHtTfQoJc2VkIC1pIC1lICdzfC1sZGJ8LWxkYi0zLjJ8ZycgLWUgJ3N8bGliZGItM3xsaWJkYi0z LjJ8ZycgZGlzdC9jb25maWd1cmUgXAoJCXx8IGRpZSAic2VkIGZhaWxlZCIKCSMgRml4IGJ1ZyAy Mzg4OAoJZXBhdGNoICR7RklMRVNESVJ9LyR7UH0tdGNzZXRhdHRyLnBhdGNoIHx8IGRpZSAiZXBh dGNoIGZhaWxlZCIKfQoKc3JjX2NvbXBpbGUoKSB7Cglsb2NhbCBteWNvbmY9IiIKCWV4cG9ydCBM SUJTPSItbHB0aHJlYWQiCglleHBvcnQgQUREQ1BQRkxBR1M9Ii1JL3Vzci9pbmNsdWRlL2RiMyIK CWNkIGJ1aWxkLnVuaXgKCS4uL2Rpc3QvY29uZmlndXJlIFwKCQktLWluZm9kaXI9L3Vzci9zaGFy ZS9pbmZvIFwKCQktLW1hbmRpcj0vdXNyL3NoYXJlL21hbiBcCgkJLS1wcmVmaXg9L3VzciBcCgkJ LS1ob3N0PSR7Q0hPU1R9IFwKCQktLXByb2dyYW0tcHJlZml4PW4gXAoJCSR7bXljb25mfSB8fCBk aWUgImNvbmZpZ3VyZSBmYWlsZWQiCgllaW5mbyAiRG9pbmcgbWFrZSBub3ciCgllbWFrZSB8fCBk aWUgImVtYWtlIGZhaWxlZCIKfQoKc3JjX2luc3RhbGwoKSB7CgljZCAke1N9L2J1aWxkLnVuaXgK CWVpbnN0YWxsIHx8IGRpZQp9Cg== 51523 2005-02-18 07:52 0000 Ebuild changed to stop block with nvi vim-6.3-r5.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA1IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L2FwcC1lZGl0b3JzL3ZpbS92aW0tNi4zLXI0LmVi dWlsZCx2IDEuMyAyMDA1LzAyLzE3IDIwOjQyOjM5IGNpYXJhbm0gRXhwICQKCmluaGVyaXQgdmlt CgpWSU1fVkVSU0lPTj0iNi4zIgpWSU1fT1JHX1BBVENIRVM9InZpbS02LjMuMDU4LXBhdGNoZXMu dGFyLmJ6MiIKVklNX0dFTlRPT19QQVRDSEVTPSJ2aW0tNi4zLjA1OC1nZW50b28tcGF0Y2hlcy50 YXIuYnoyIgoKU1JDX1VSST0iJHtTUkNfVVJJfQoJZnRwOi8vZnRwLnZpbS5vcmcvcHViL3ZpbS91 bml4L3ZpbS0ke1ZJTV9WRVJTSU9OfS50YXIuYnoyCglubHM/ICggZnRwOi8vZnRwLnZpbS5vcmcv cHViL3ZpbS9leHRyYS92aW0tJHtWSU1fVkVSU0lPTn0tbGFuZy50YXIuZ3ogKQoJbWlycm9yOi8v Z2VudG9vLyR7VklNX0dFTlRPT19QQVRDSEVTfQoJbWlycm9yOi8vZ2VudG9vLyR7VklNX09SR19Q QVRDSEVTfSIKClM9JHtXT1JLRElSfS92aW0ke1ZJTV9WRVJTSU9OLy59CkRFU0NSSVBUSU9OPSJW aW0sIGFuIGltcHJvdmVkIHZpLXN0eWxlIHRleHQgZWRpdG9yIgpLRVlXT1JEUz0ieDg2IHNwYXJj IG1pcHMgfnBwYyB+YW1kNjQgfmFscGhhIH5pYTY0IH5hcm0gfmhwcGEgfnBwYzY0IH5zMzkwIgpJ VVNFPSIke0lVU0V9IG5scyIKUFJPVklERT0idmlydHVhbC9lZGl0b3IiCkRFUEVORD0iJHtERVBF TkR9Cgl+YXBwLWVkaXRvcnMvdmltLWNvcmUtJHtQVn0iCg== 51524 2005-02-18 07:53 0000 Change vim.eclass to install links with v prefix vimpatch text/plain KioqIHZpbS5lY2xhc3MJVHVlIEZlYiAgOCAxMzo0Mzo0NiAyMDA1Ci0tLSAvdXNyL3BvcnRhZ2Uv ZWNsYXNzL3ZpbS5lY2xhc3MJRnJpIEZlYiAxOCAwNzo0MTo1NSAyMDA1CioqKioqKioqKioqKioq KgoqKiogMzIxLDMyNiAqKioqCi0tLSAzMjEsMzI3IC0tLS0KICAJaWYgW1sgIiR7TVlfUE59IiA9 PSAidmltLWNvcmUiIF1dIHx8CiAgCQkJKCBbWyAiJHtNWV9QTn0iID09ICJ2aW0iIF1dICYmIHVz ZSBtaW5pbWFsICk7IHRoZW4KICAJCW15Y29uZj0iLS13aXRoLWZlYXR1cmVzPXRpbnkgXAorIAkJ CS0td2l0aC12aW0tbmFtZT12aW0gXAogIAkJCS0tZW5hYmxlLWd1aT1ubyBcCiAgCQkJLS13aXRo b3V0LXggXAogIAkJCS0tZGlzYWJsZS1wZXJsaW50ZXJwIFwKKioqKioqKioqKioqKioqCioqKiAz NjEsMzY2ICoqKioKLS0tIDM2MiwzNjggLS0tLQogIAkJCSMgZG9uJ3QgdGVzdCBVU0U9WCBoZXJl IC4uLiBzZWUgYnVnICMxOTExNQogIAkJCSMgYnV0IG5lZWQgdG8gcHJvdmlkZSBhIHdheSB0byBs aW5rIGFnYWluc3QgWCAuLi4gc2VlIGJ1ZyAjMjAwOTMKICAJCQlteWNvbmY9IiR7bXljb25mfSAt LWVuYWJsZS1ndWk9bm8gYHVzZV93aXRoIHZpbS13aXRoLXggeGAiCisgCQkJbXljb25mPSIke215 Y29uZn0gLS13aXRoLWV4LW5hbWU9dmV4IC0td2l0aC12aWV3LW5hbWU9dnZpZXciCiAgCiAgCQll bGlmIFtbICIke01ZX1BOfSIgPT0gImd2aW0iIF1dIDsgdGhlbgogIAkJCW15Y29uZj0iJHtteWNv bmZ9IC0td2l0aC12aW0tbmFtZT1ndmltIC0td2l0aC14IgoqKioqKioqKioqKioqKioKKioqIDUz Nyw1NDQgKioqKgogIAkJZG9iaW4gc3JjL3ZpbQogIAkJbG4gLXMgdmltICR7RH0vdXNyL2Jpbi92 aW1kaWZmICYmIFwKICAJCWxuIC1zIHZpbSAke0R9L3Vzci9iaW4vcnZpbSAmJiBcCiEgCQlsbiAt cyB2aW0gJHtEfS91c3IvYmluL2V4ICYmIFwKISAJCWxuIC1zIHZpbSAke0R9L3Vzci9iaW4vdmll dyAmJiBcCiAgCQlsbiAtcyB2aW0gJHtEfS91c3IvYmluL3J2aWV3IFwKICAJCQl8fCBkaWUgIi91 c3IvYmluIHN5bWxpbmtzIGZhaWxlZCIKICAJCWlmIFtbICQoZ2V0X21ham9yX3ZlcnNpb24gKSAt Z2UgNyBdXSAmJiB1c2UgdmltLXBhZ2VyIDsgdGhlbgotLS0gNTM5LDU0NiAtLS0tCiAgCQlkb2Jp biBzcmMvdmltCiAgCQlsbiAtcyB2aW0gJHtEfS91c3IvYmluL3ZpbWRpZmYgJiYgXAogIAkJbG4g LXMgdmltICR7RH0vdXNyL2Jpbi9ydmltICYmIFwKISAJCWxuIC1zIHZpbSAke0R9L3Vzci9iaW4v dmV4ICYmIFwKISAJCWxuIC1zIHZpbSAke0R9L3Vzci9iaW4vdnZpZXcgJiYgXAogIAkJbG4gLXMg dmltICR7RH0vdXNyL2Jpbi9ydmlldyBcCiAgCQkJfHwgZGllICIvdXNyL2JpbiBzeW1saW5rcyBm YWlsZWQiCiAgCQlpZiBbWyAkKGdldF9tYWpvcl92ZXJzaW9uICkgLWdlIDcgXV0gJiYgdXNlIHZp bS1wYWdlciA7IHRoZW4K 51545 2005-02-18 12:44 0000 Script to make vi the best available vi vi text/plain aWYgWyAhIC1mIC91c3IvYmluL3ZpIF07IHRoZW4KCglpZiBbIC1mIC91c3IvYmluL3ZpbSBdOyB0 aGVuCgkJYWxpYXMgdmkgdmltCgllbGlmIFsgLWYgL3Vzci9iaW4vbnZpIF07IHRoZW4KCQlhbGlh cyB2aSBudmkKCWZpCgpmaQo= 51555 2005-02-18 16:13 0000 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 text/plain LS0tIG52aS0xLjgxLjUtcjIuZWJ1aWxkCTIwMDUtMDItMTkgMDA6MjM6MTcuMDAwMDAwMDAwICsw MTAwCisrKyBudmktMS44MS41LXIzLmVidWlsZAkyMDA1LTAyLTE5IDAxOjA2OjQ5LjIwNjA0MDQ0 MCArMDEwMApAQCAtMiw3ICsyLDcgQEAKICMgRGlzdHJpYnV0ZWQgdW5kZXIgdGhlIHRlcm1zIG9m IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgogIyAkSGVhZGVyOiAvdmFyL2N2c3Jv b3QvZ2VudG9vLXg4Ni9hcHAtZWRpdG9ycy9udmkvbnZpLTEuODEuNS1yMi5lYnVpbGQsdiAxLjkg MjAwNS8wMS8wMSAxMzozMjo0MyBlcmFkaWNhdG9yIEV4cCAkCiAKLWluaGVyaXQgZXV0aWxzCitp bmhlcml0IGV1dGlscyBhbHRlcm5hdGl2ZXMKIAogREVTQ1JJUFRJT049IlZpIGNsb25lIgogSE9N RVBBR0U9Imh0dHA6Ly93d3cuYm9zdGljLmNvbS92aS8iCkBAIC0zNiw2ICszNiw3IEBACiAJCS0t bWFuZGlyPS91c3Ivc2hhcmUvbWFuIFwKIAkJLS1wcmVmaXg9L3VzciBcCiAJCS0taG9zdD0ke0NI T1NUfSBcCisJCS0tcHJvZ3JhbS1wcmVmaXg9biBcCiAJCSR7bXljb25mfSB8fCBkaWUgImNvbmZp Z3VyZSBmYWlsZWQiCiAJZWluZm8gIkRvaW5nIG1ha2Ugbm93IgogCWVtYWtlIHx8IGRpZSAiZW1h a2UgZmFpbGVkIgpAQCAtNDUsMyArNDYsMTUgQEAKIAljZCAke1N9L2J1aWxkLnVuaXgKIAllaW5z dGFsbCB8fCBkaWUKIH0KKworcGtnX3Bvc3RpbnN0KCkgeworCQlhbHRlcm5hdGl2ZXNfbWFrZXN5 bSAvdXNyL2Jpbi92aSAvdXNyL2Jpbi92aW0gL3Vzci9iaW4vbnZpCisJCWFsdGVybmF0aXZlc19t YWtlc3ltIC91c3IvYmluL2V4IC91c3IvYmluL3ZpbSAvdXNyL2Jpbi9uZXgKKwkJYWx0ZXJuYXRp dmVzX21ha2VzeW0gL3Vzci9iaW4vdmlldyAvdXNyL2Jpbi92aW0gL3Vzci9iaW4vbnZpZXcKK30K KworcGtnX3Bvc3RybSgpIHsKKwkJYWx0ZXJuYXRpdmVzX21ha2VzeW0gL3Vzci9iaW4vdmkgL3Vz ci9iaW4vdmltIC91c3IvYmluL252aQorCQlhbHRlcm5hdGl2ZXNfbWFrZXN5bSAvdXNyL2Jpbi9l eCAvdXNyL2Jpbi92aW0gL3Vzci9iaW4vbmV4CisJCWFsdGVybmF0aXZlc19tYWtlc3ltIC91c3Iv YmluL3ZpZXcgL3Vzci9iaW4vdmltIC91c3IvYmluL252aWV3Cit9Cg== 51556 2005-02-18 16:14 0000 Patch against vim.eclass to use alternatives.eclass to manage symlinks bug69852-vim.eclass-alternatives.patch text/plain LS0tIC91c3IvcG9ydGFnZS9lY2xhc3MvdmltLmVjbGFzcwkyMDA1LTAyLTA4IDIyOjQzOjI0LjAw MDAwMDAwMCArMDEwMAorKysgdmltLmVjbGFzcwkyMDA1LTAyLTE5IDAwOjU5OjQ5LjAwMDAwMDAw MCArMDEwMApAQCAtMjMsNyArMjMsNyBAQAogIyAtYXF1YSAtZ3RrIC1tb3RpZiBuZXh0YXcgICAg ICBORVhUQVcgKDcrKQogIyAtYXF1YSAtZ3RrIC1tb3RpZiAtbmV4dGF3ICAgICBBVEhFTkEKIAot aW5oZXJpdCBldXRpbHMgdmltLWRvYyBmbGFnLW8tbWF0aWMgdmVyc2lvbmF0b3IgZmRvLW1pbWUK K2luaGVyaXQgZXV0aWxzIHZpbS1kb2MgZmxhZy1vLW1hdGljIHZlcnNpb25hdG9yIGZkby1taW1l IGFsdGVybmF0aXZlcwogCiAjIFN1cHBvcnQgLWN2cyBlYnVpbGRzLCBldmVuIHRob3VnaCB0aGV5 J3JlIG5vdCBpbiB0aGUgb2ZmaWNpYWwgdHJlZS4KIE1ZX1BOPSIke1BOJS1jdnN9IgpAQCAtNTM1 LDEyICs1MzUsNiBAQAogCiAJZWxzZQogCQlkb2JpbiBzcmMvdmltCi0JCWxuIC1zIHZpbSAke0R9 L3Vzci9iaW4vdmltZGlmZiAmJiBcCi0JCWxuIC1zIHZpbSAke0R9L3Vzci9iaW4vcnZpbSAmJiBc Ci0JCWxuIC1zIHZpbSAke0R9L3Vzci9iaW4vZXggJiYgXAotCQlsbiAtcyB2aW0gJHtEfS91c3Iv YmluL3ZpZXcgJiYgXAotCQlsbiAtcyB2aW0gJHtEfS91c3IvYmluL3J2aWV3IFwKLQkJCXx8IGRp ZSAiL3Vzci9iaW4gc3ltbGlua3MgZmFpbGVkIgogCQlpZiBbWyAkKGdldF9tYWpvcl92ZXJzaW9u ICkgLWdlIDcgXV0gJiYgdXNlIHZpbS1wYWdlciA7IHRoZW4KIAkJCWxuIC1zIC91c3Ivc2hhcmUv dmltL3ZpbSR7VklNX1ZFUlNJT04vLy4vfS9tYWNyb3MvbGVzcy5zaCBcCiAJCQkJCSR7RH0vdXNy L2Jpbi92aW1wYWdlcgpAQCAtNTY4LDEyICs1NjIsNyBAQAogdXBkYXRlX3ZpbV9zeW1saW5rcygp IHsKIAlsb2NhbCBmIHN5bXMKIAotCSMgU29tZSBvZiB0aGVzZSBhcmUgcHJvdmlkZWQgYWxyZWFk eSBvbiB4ODYtZmJzZCwgYnVnIDY5NTM1LgotCWlmIHVzZSB4ODYtZmJzZCA7IHRoZW4KLQkJc3lt cz0idmltZGlmZiBydmltIHJ2aWV3IgotCWVsc2UKLQkJc3ltcz0idmkgdmltZGlmZiBydmltIGV4 IHZpZXcgcnZpZXciCi0JZmkKKwlzeW1zPSJ2aW1kaWZmIHJ2aW0gcnZpZXciCiAKIAkjIE1ha2Ug b3IgcmVtb3ZlIGNvbnZlbmllbmNlIHN5bWxpbmssIHZpbSAtPiBndmltCiAJaWYgW1sgLWYgJHtS T09UfS91c3IvYmluL2d2aW0gXV07IHRoZW4KQEAgLTU5NSw5ICs1ODQsMTIgQEAKIAkJZG9uZQog CWZpCiAKLQkjIFRoaXMgd2lsbCBzdGlsbCBicmVhayBpZiB5b3UgbWVyZ2UgdGhlbiByZW1vdmUg dGhlIHZpIHBhY2thZ2UsCi0JIyBidXQgdGhlcmUncyBvbmx5IHNvIG11Y2ggeW91IGNhbiBkbywg ZWg/ICBVbmZvcnR1bmF0ZWx5IHdlIGRvbid0Ci0JIyBoYXZlIHRyaWdnZXJzIGxpa2UgYXJlIGRv bmUgaW4gcnBtLWxhbmQuCisJIyBUaGVzZSBhcmUgcHJvdmlkZWQgYWxyZWFkeSBvbiB4ODYtZmJz ZCwgYnVnIDY5NTM1LgorCWlmICEgdXNlIHg4Ni1mYnNkIDsgdGhlbgorCQlhbHRlcm5hdGl2ZXNf bWFrZXN5bSAvdXNyL2Jpbi92aSAvdXNyL2Jpbi92aW0gL3Vzci9iaW4vbnZpCisJCWFsdGVybmF0 aXZlc19tYWtlc3ltIC91c3IvYmluL2V4IC91c3IvYmluL3ZpbSAvdXNyL2Jpbi9uZXgKKwkJYWx0 ZXJuYXRpdmVzX21ha2VzeW0gL3Vzci9iaW4vdmlldyAvdXNyL2Jpbi92aW0gL3Vzci9iaW4vbnZp ZXcKKwlmaQogfQogCiBwa2dfcG9zdGluc3QoKSB7Cg==