[arch-dev-public] About the vim packages (Opinions needed)

[Aaron Griffin]

On Sun, Oct 11, 2009 at 3:45 PM, Tobias Kieslich <tobias at justdreams.de> wrote:
> Now, I think that gives a nice and very clear distinction between vim
> (mainly for console user) and gvim (for developers, but also people who
> run the vim command in the terminal). Note that after installing the gvim
> package, the vim command invokes a more powerful, python and X enabled
> binary.
>
> I am getting feature requests, to put it nicely, about enabling python
> in vim. I'm opposed to that for two reasons:
>  - upon the return of ruby people will pester me about ruby support
>   becuase python is in there and why not ruby .. whine .. blah
>  - I think there is a clear distinction between vim for the console and
>   vim for serious development, and the current layout shows that nicely
>
> The arguments about including python are mainly like that: But when I am
> on this server, or on this very small box, too small to run X and I
> wanna develop in python etc. I don't think these are valid arguments
> because they are rare cases. And if it's really true, you can always
> build a custom python enable smaller vim.

It's a bit bold to state that gvim is for "serious developers". I use
vim at home and at work for day to day development, and use gvim
approximately 10% of the time (when I need to do something on a
Windows VM, because cmd.exe sucks). On a Linux machine, I don't think
I've actually started gvim in like 3 years.

>  - first of all I think that's a non issue, becuase Arch is binary based
>   and rebuilding is not really necessary

This relates directly to the above. Yes, Arch is binary based, but if
vim isn't compiled with +python support, I know I am going to rebuild
it. If people give lots of feature requests that are denied, they will
simply rebuild it from ABS. That's what we do. The proposal Xavier had
was to expedite that process. I don't really care HOW it's
accomplished, but he's correct that having these crazy scripts to
download stuff is overkill.

There's a middle-ground, however. We can do the download once, make a
tarball of it, and stick it in ftp/other/ for ABS users to rebuild
from. I believe this was proposed in a PKGBUILD Xavier emails around
(a _mksrc function similar to libfetch). It doesn't have to use CVS,
but if we provide a tarball somewhere and simply base the PKGBUILD off
that, instead of doing complex bash gymnastics, we meet in the middle
here.

The gist of this is, if you're denying these feature requests (which
is totally fine), then expect people to be rebuilding a lot. If this
happens, then the PKGBUILD probably needs to be a tad plainer /
quicker