We have the eselect system for selecting among various version of things. All of the various vis should install under a unique name and should link to vi, ex etc via the eselect system. Let's get some of the gentoo choice back into the vi portion.
*** Bug 148139 has been marked as a duplicate of this bug. ***
So, an eselect module for this purpose has already been written, but so far it hasn't been included in the standard eselect distribution. I'm asking eselect folks to do that now. Once that gets done, I'll make the appropriate changes in nvi, vim.eclass, elvis, vile, and xvile.
Okay, as an update, app-editors/vim-7.0.109 and app-editors/gvim-7.0.109 now use the app-admin/eselect-vi package to configure the /usr/bin/vi symlink, and elvis, vile, and xvile will shortly. All that app-editors/nvi needs to do is add the lines: einfo "Setting /usr/bin/vi symlink" eselect vi set "${PN}" in their ebuild's pkg_postinst() phase, and add the lines: einfo "Updating /usr/bin/vi symlink" eselect vi update in their ebuild's pkg_postrm() phase. This should be with a rev bump, and that revision should be package.masked for the time being.
(In reply to comment #3) > All that app-editors/nvi needs to do is in addition to what you wrote, it would need to depend on eselect-vi. There is a problem with that: eselect-vi depends on >=eselect-1.0.6, which is not in the tree. I'll update nvi as soon as I'm able to test eselect-vi, thanks for the good work. :)
Oh, yeah, forgot the DEPEND... Yeah, you can actually just add the 1.0.6 version to /etc/portage/profile/package.provided for now and run it with 1.0.5... it works fine. The 1.0.6 is just so that there's no possible chance of a collision between the two packages (vi.eselect is split from the old eselect package, although it wasn't ever installed with eselect, just distributed with it).
(In reply to comment #5) > Oh, yeah, forgot the DEPEND... It should be RDEPEND, not DEPEND. (This appears to be wrong in vim, and some of the other ebuilds using eselect-vi don't have it as a dependency at all.) > Yeah, you can actually just add the 1.0.6 > version to /etc/portage/profile/package.provided for now and run it with > 1.0.5... it works fine. The 1.0.6 is just so that there's no possible chance of > a collision between the two packages (vi.eselect is split from the old eselect > package, although it wasn't ever installed with eselect, just distributed with > it). Thanks for the info. nvi -r4 will be in the tree later tonight, hardmasked, assuming I don't run into any problems. One other note, would you (anyone) remove vim's block on nvi?
nvi-1.81.5-r4 added. One last request: before eselect-vi gets unmasked, could it be updated to also make /usr/bin/ex and /usr/bin/view symlinks, and possibly any other relevant ones?
(In reply to comment #6) > It should be RDEPEND, not DEPEND. It should be DEPEND, since this is run during the ebuild, and not afterwards. > (This appears to be wrong in vim, and some of the other ebuilds using > eselect-vi don't have it as a dependency at all.) I added the DEPEND to the ebuilds I had forgotten it in earlier. > One other note, would you (anyone) remove vim's block on nvi? Removing them now, should be fixed in CVS in a bit. (In reply to comment #7) > before eselect-vi gets unmasked, could it be updated to also make > /usr/bin/ex and /usr/bin/view symlinks, and possibly any other > relevant ones? Sure, I was already thinking about that. Besides vi, ex, and view, can you or anyone else think of any other standard symlinks it should provide?
(In reply to comment #8) > (In reply to comment #6) > > It should be RDEPEND, not DEPEND. > > It should be DEPEND, since this is run during the ebuild, and not afterwards. That's not really relevant. It should not be in DEPEND because it is unnecessary for emerge --buildpkgonly, and it has to be in RDEPEND since it is required for emerge --usepkgonly. > > before eselect-vi gets unmasked, could it be updated to also make > > /usr/bin/ex and /usr/bin/view symlinks, and possibly any other > > relevant ones? > > Sure, I was already thinking about that. Besides vi, ex, and view, can you or > anyone else think of any other standard symlinks it should provide? For nvi, those three are the only ones.
(In reply to comment #9) > (In reply to comment #8) > > > > Sure, I was already thinking about that. Besides vi, ex, and view, can you or > > anyone else think of any other standard symlinks it should provide? > > For nvi, those three are the only ones. No, there should also be a "nex". (However, nex should probably be there no matter what, and not be set by eselect. Currently, it's missing.)
> > For nvi, those three are the only ones. > > No, there should also be a "nex". (However, nex should probably be there no > matter what, and not be set by eselect. Currently, it's missing.) I'm not so sure it's necessary, since you can just as well run 'nvi -e', and scripts shouldn't be using /usr/bin/nex anyway (they should use ex), but I don't have a problem with it either. I'll restore creation of that, as well as nview.
As an update, now in CVS is eselect-vi-1.1, which provides symlinks for ex and view, as well as symlinks for the vi, ex, and view man pages. The vim.eclass has been updated to handle this properly. Everything is still masked for now (still waiting on eselect-1.0.6).
Created attachment 98067 [details, diff] vi.eselect.patch eselect-vi-1.1 has serious problems. Please apply this patch. eselect-vi tries to create /usr/bin/vi twice and always complains that it already exists the second time. Backslashes are missing. remove_symlinks returns no meaningful exit code (it returns whether /usr/share/man/man1/view.1.gz existed already, regardless of anything else), its return status should not be checked.
Oops, thanks for pointing that out. I've fixed it in eselect's svn, and I'll push out 0.1.1 later tonight.
So, app-admin/eselect-1.0.6 is in the tree now. Lets test all this out some more, but I think it's nearly ready for unmasking. How about you, Harald?
Well, there's still the issue that # rm /usr/share/man/man1/view.1.gz # eselect vi set nvi won't work properly (as mentioned before), when the expected behaviour (at least, expected by me) is to simply recreate the symlink. Other than that, though, I have no problems with unmasking it.
Hmm, I'll poke that some more a little later today. Also, it's come to my attention that man pages aren't always installed gzipped by all versions of portage, they may be bzipped, or have no compression at all. So, I've gotta do a little bit better handling there, too. I'll take a look at it on Saturday.
Hi, sorry, I've been kinda swamped with my new job. I'm almost done poking and prodding eselect-vi and sending out a new version. I should have time this Saturday to do that. All I have left is to handle more intelligently making the man page symlinks, since sometimes man pages are installed bzip2'd, other times gzip'd, and others without any compression at all.
Okay, all that is done and tested. As soon as others here can test app-admin/eselect-vi-1.1.3 and confirm I didn't do anything stupid, I'll unmask everything. (It should hit your local distfiles/rsync mirrors in a few hours).
And, it's unmasked! Enjoy! If anything else wrong happens with the new eselect-vi, please reopen this bug. I'll re-mask it if necessary.
Sorry, reopening this until bug #152620 is closed.
Okay, now it's /really/ fixed. Thanks for your patience.
