Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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