Arch Linux

Oh, and his report started with "I was hoping that vi would be vi, not vim. Yet core/vi is Vi Improved... Another strange thing is that vim requires ruby and python as dependencies. After talking with a few people in #vim on freenode I learned that those are not required for it's operation. :> I find it strange, futhermore, that the article listed here says vim sources /etc/vimrc, but I had to symlink /etc/vimrc to my /etc/virc for my settings to be noticed. The article is linked here: http://www.archlinux.org/news/336/

I moved away from Debian because of package names that were deceiving only to find that Arch has done this with vim?"

That's like 5 different issues all in one comment. Let's just stick to the "rename vi to something else" for this report please.

For the record, I'd be fine with renaming the package, but that doesn't automatically mean we're going to package some other vi unless some dev cares enough - that's what I thought was stupid about the original bug report. The "OMG you're making a choice" argument is moot if there are no other vi packages in the repos.

At the beginning of the original report, I was under the impression nvi was the official successor to vi. After doing more research I learned differently. I tried to apologize for how horribly I came across and discussed this subject further with a few on #archlinux. After a tiresome debate I gave up. Thank you, Grigorios for opening this ticket, but I had no intention to continue it... :>

Good day...

PS: The "OMG you're making a choice" argument is moot if there are no other vi packages in the repos. <-- I still consider that misleading as it gives no notice saying what it is exactly... this reminds me of the virtual/ ebuilds on Gentoo. :>

Well, it is valid to some extent - IF we have a call for a different 'vi'. As far as I can tell, there are lots of vi's out there. nvi, elvis, and apparently even the original vi: http://ex-vi.sourceforge.net/

Well, calling it "misleading" is very very different from saying "you're not allowing us to choose". That is all I was pointing out.

I have a hard time to express how annoying that whole thing is and it is certainly more about politics than it is about package layout. Here is a quick sum up, that hopefully can be another base for a discourse on how our vi/vim should be laid out ... this year ...
It seems people are not happy about vim having vi capabilities and the purity nazis are starting to complain. Apart from stating the f...ing obvious, that our vi is actually a vim in disguise, I have NOT yet heard any reason why vim set to the compatible mode appears to be such a horrific and terrifying yet poor excuse for an actual vi executable. Ah well, I'm sure somebody will enlighten me.

Soooooo. the state of the affair. Since I don't feel like changing the layout around anytime somebody cries me a river here is the status quo.
1. LSB requires a vi binary, has to be named vi, shall act like vi (our little vim does that just fine btw.) is a requirement for a Linux system. Period. In English: providing vim-tiny does not slice it as long as it has no vi binary. And if we rename the package but leave the binary, what's the point?

Referring to vi below that point means referring to our vi package, unless stated differently
2. vi serves the runtime for all vim packages. That means it might come with some files that are actually used only by vim and gvim. Big deal. This little overhead prevents packaging errors and wrong dependencies. Splitting up the runtime is way to error prone.

3. python and ruby dependencies were feature requests that came in over the years. Perl is essential AFAIK because some stuff in the runtime actually needs it as well as some more popular plugins. From quick tries, vim starts and tries to load the *.so files and exits when it does not find them(for python, perl and ruby). I will NOT provide binaries for all cases such as with Python but not Ruby, with Perl but not Python etc you name it .. did you know we could link against scheme as well?. They can NOT be made makedepends.

4. we could of cause serve more versions of *vi*. The only advantage I can see of having something like elvis/nvi in core, would be that the testing cycle for vi/vim/gvim disappears, that is caused by the fact that vi, where everything depends on must be put to testing and that holds of vim/gvim update for the masses. At that point we could have a simple vim(no X, no python,perl,ruby) and a heavier vim with ALL the goodies those would have to conflict, and both provide the runtime so that gvim can depend on that package.

I know we could do so many things and we could kiss KISS goodbye too ... Did I mention that I'm really annoyed by politics?

Yay!

One minor thing to note: I thought someone said some of the plugin libs COULD be optional - try building with rub enabled then removing ruby or something. I know it DOES work that way on windows, at least

That's what I did with our vim. It's build against ruby, I pacman -Rd ruby and it starts, tries to load lib-bllah-ruby.so, doens't find it complains and exit. So that means it is a hard dependency. Ruby for sure. I can try Python and Perl but my guess is the result will be equivalent.

WOW :)
With no.3 Tobias said deals  FS#13240  .

It would be nice if a post to the forums were made explaining why vim requires these scripting languages as hard dependencies for dumb users like me. Hopefully I'll be the last one to cause grief about this... :>

Sleepy_coder: As explained in the other bug, I have cooled down a bit and I'm sorry if it was too offensive.
Do you have a specific thread in the forum where these things should be explained? If so, please have a pointer for me. If not, I would prefer the ML for discussions on that topic because the threading of the ML makes it easier to follow and it will get heated, I can almost guarantee :P
Anyway, after a night of sleep, some second and third thoughts, there are things that are appealing about changing the layout, however, so far there are minor issues in it that I don't like and I have no idea (yet) how to solve it.

First of all, instead of quoting from memory, I did some research and very much to my surprise, vi is NO requirement in LSB 3.1.0. Either anymore or has never been. So I was wrong on 1. But anyway, vi(as in binary) should be provided in core, I don't care too much about ex(binary) because we ship ed.

As stated in 4. it would be beneficial, to have vi(as in the package) replaced in core because we can make vi/vim/gvim releases without waiting for the testing cycle. Furthermore, because in our layout vi provides the entire runtime (8MB/35MB compressed/deflated) replacing it would significantly cut down on the size of core. A good thing IMHO. I played a bit with nvi this morning and it looks like it would get the job done. Dependencies are db and bash, at least db is a bit odd but they are both in core anyway so that's no show stopper. nvi installs three binaries: nvi, nex and nview. Very straight forward. We can provide a symlink from vi to nvi and we would be done. I would provide NO symlink from ex to nex, I will explain further down.

That would enable us to move everything vim related to extra. We will get rid of everything vi-related including the .virc issues people are nagging about. I would still provide 3 vim packages vim-normal, vim-full, gvim. Names are negotiable but you get the gist. Why 3? Because I concur that bringing in three complete scripting languages, just to get an editor running that is supposed to be on the lighter side is quite heavy. So how shall that look like? First here is the challenge: which package shall provide the 'vim' binary ore the symlink or whatever? Now please note (or remember if around for long enough) we had symlink magic in vim in the past, making the post_install/uninstall methods taking care of pointing to the latest and greatest installed binary. That was, let's say not ideal, you can call it buggy too :P
So what will it be about?
vim-normal: provides the runtime,
____________moderate feature set,
____________no perl/python/ruby, no X,
____________provides an actual ex binary more capable than nvi (nex)
vim-full: depends on vim-normal,
____________full feature set,
____________with perl/python/ruby
____________X for easy resizing, server capabilities etc
gvim: same as vim-full, but with GTK2

Now, keep in mind that this is not ideal, because vim has this nifty mechanism that if invoked as vim it is command line, if invoked as gvim(symlink) it has a GUI. That makes vim-full and gvim pretty much the same and the overhead
of a binary compiled with GTK2 but started just as vim is pretty much neglectable!

That makes me think, falling back to two packages vim(without bells and whistles) and gvim(everything) should be good enough. It just leaves us with the treaded problem: How to deal with that bloody vim symlink when gvim is installed? Here is a schema that might work, but getting the post_install magic working reliably(that is the key word) is a b**** to get it right.
vim: provides 'vim-normal'
gvim: provides 'vim-full' and a 'gvim' symlink to it
neither provide a vim symlink in the package. If only vim is installed a vim symlink is created post_install pointing to vim-normal. If gvim is installed a vim symlink is created pointing to vim-full. Note: that would have to be done for all generic binary names such as rvi, view etc. The point is, we cannot just symlink anyway we want, because vim controls its behaviour according to the symlink name it got called as!

I hope this provides both, a reasonable suggestion and an explanation, why the issue is not easy to deal with. The vim layout can not just be changed a little bit, becuase verything depends on everything else. As unsatisfying as our current layout seems to some people, it is not a bad compromise, it is very robust (as compared to the symlink magic) and it took a long time to get it right.

Edit: I have no issues to take that to the ML, but there will be no perfect solutiuon as there are too many people wanting different things. However, just let people talk about it.

I wasn't offended, just sad that I seemed to have reopened an old wound... The only thing that I think wouldn't be challenged much is replacing core/vi with something smaller. Sadly, packaging the original vi that Aaron found would be a bad move considering it's problems. nvi seems like a great alternative but it'd probably be best to see what the majority of people on the mailinglist would prefer... The vim restructuring would also need a fierce mailinglist debate... :> To be honest, I think vim would be nicer packaged only as extra/vim and extra/vim-full. vim-full being the ruby/python/perl and gvim extras. The only issue would be the percentage of those who are server admins that don't need/install X that need those scripting language extras... I would start the conversation on the mailing list, but I don't even know how to join that. 0_o Thank you so much for looking into it though...

Regards

sleepy_coder: http://www.archlinux.org/mailman/listinfo/arch-general
just go there, follow the process. It's really easy.

Wow lots of text, and you guys seem to have it under control. I'll add my small comments:

* I am in full agreement that putting a smaller / crappier vi in core would be a good idea, based on this discussion
* Were it up to me, I would just provide vim and gvim, with all features - but that's because I use most of them and don't care about a few extra (ruby) deps.
* I would name "vim-full" to "vim-huge" to be more consistent with the vim build scripts. Also it sounds funnier

Regarding ed: http://www.archlinux.org/pipermail/arch-dev-public/2009-February/010177.html
I agree with phrakture. What is the point of the vim-normal package? Cant nvi provide ex too?
If the way the vim family build process changes too, regarding the patchlevel, part of the other bug report, users who wany a tiny vim can use ABS to build it if they want to. Or use nvi.

Okay, let's get this thing rolling a bit. Here are the caveats of the above discussion:

1. we would have no 'vi' package anymore as in pacman -S vi would not show anything. For some people the world might come to an end ... and yes there are irony tags ...
2. as much as I like the vim-huge idea, it does sound funnier and I'm all for it, it probably is better to provide a "vim" package and a "gvim" package for the sake of what package names people would expect.

dolby: I just thought the ex from the vim package might be more capable. But for the vast majority of things nex is probably just fine, even too powerful already. I like ex but most people don't know how to use it anyway. However, nex is sufficient for what I do with it.

That would leave us with the following layout:
-nvi: in core, providing vi and ex symlinks (guys this will need thorough testing, the installer needs that stuff!)
-vim: it will be a vim with a big feature-set, but explicitly excludes Perl,Python,Ruby and X.
_____However, it will provide the runtime, as such it will a dependency for gvim. Shall make the people happy,
_____who prefer vim the slim way.
-gvim: feature set:huge, all scripting languages, we might even think about Scheme just because it is fun.
_____I think though, the last time I checked, the specific scheme they are looking for is only in 'unsupported',
_____not worth it o bring it to extra for that.

The following is subject to some extensive testing: Since the binary (in gvim package) can be invoked as vim and gvim we might be able to get away with gtk2 and the hardcore X-libs as make- and optdepends. This would allow the package to be installed on server like environments with only bringing in some minor X libraries that are installed on many servers anyway(for freetype support in gd for php and things like that). This way $admin can take advantage
of Perl,Ruby,Python support without too much penalties. The oddity is that they would have to pacman -S gvim though which is a tad counter intuitive ...

Now "all" we got to do is to get this vim binary symlink structure right on post_install. And that's a tough one...
Can anyone think of a way to get that sort of flexibility without symlink magic?


And yes, I coded too much php lately, my string delimiters are extremely inconsistent ...

What if the current vi just changed its name to vim-core, and everything else were the same, at least regarding the naming scheme?
That would be somehow consistent to other packages eg. dbus.
I can see the benefits not having a vim in base, im just wondering if they are that great.

And yes i know this is back where we started, but the original report was about the package name.
Since the particular scheme started, i dont remember bug reports about that, and i ve already said i think its a good compromise.
The only thing thats troubling me, is that vi even if its just renamed vim-core would still use a virc.

First of all, that stuff shall go testing this weekend.

dolby, the only reason why I would like a vim in base is the support for tabs. Personal preference. Apart from that, nvi is so much easier and having vim out of core makes updates so much faster too. All that also gets rid of virc, many people consider that a good thing.
I made one little change to the layout such as that I leave the vi package in place and don't call it nvi. It installs 'vi' binary by default anyway.

I am perfectly fine with any scheme you choose follow.
One question. What happens if i dont install nvi at all? Do i still get a vi from vim (incl. manpages)?
This is for example how Slackware does this in a post install script in vim:
# If there's no vi link, take over:
if [ ! -r usr/bin/vi ]; then
( cd usr/bin ; ln -sf vim vi )
fi

But then that will give us file conflicts if you install nvi later

True i neglected to think of it the other way around.
I only considered conflicts regarding manpages, and tried to build nvi from AUR to check but the script doesnt work.

yeah this is exactly where the symlink approach sucks and why it is so damn hard to get it right

status on this?

We will use nvi in core, yet we will call it vi as that is what everyone expects as an editor in the ver base group of packages. It is available in testing.