FS#19087 - [vim/gvim] Packaging as mutually exclusive

Attached to Project: Arch Linux
Opened by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 07:47 GMT
Last edited by Dan Griffiths (Ghost1227) - Monday, 19 April 2010, 03:05 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Tobias Kieslich (tobias)
Dan Griffiths (Ghost1227)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

I propose the making gvim independent from vim and mutually exclusive (conflicting
with each other), for several reasons:

- The symlink juggling (see vim.install, gvim.install) is complicated and goes against
The Arch Way of simplicity. Making the packages independent would make all the symlink
logic in the PKGBUILD and .INSTALL files unneeded.

- There is no real reason to keep vim-normal around when gvim is installed. vim-big
also works in a terminal, when X is not running. The editors from core (e.g. vi or
nano) are much better suited as a "fallback editor" should (g)vim become unusable.

- Some symlinks (e.g. vimdiff) always stay linked to vim-normal. This means I cannot
get the full vim-big featureset if I try to use vimdiff.

- Maintaining my own builds of both packages (I use rubyinterp) is difficult. Because
gvim depends on the same version of vim, I must uninstall the old version of gvim and
install the new vim before I can build a new gvim. When vim and gvim are mutually
exclusive, the PKGBUILDs would be largely identical and, I believe, easier to maintain.

---

The attached file contains new source packages for both vim and gvim. Changes are:

Made vim and gvim independent and mutually exclusive.
- Gets rid of the symlink mess.
- Easier to maintain, I believe.

Added rubyinterp back to gvim. This builds fine for me.
I believe the issue with the Arch packages was that the
patches were applied from the wrong directory.

Used make -j1 due to race conditions during install.
I noticed random install failures (e.g. vimtutor).

Simplified fetch_patches a bit:
- The "sed" is pointless now that rsync is used.
- Used rsync --exclude to skip downloading the .gz archives.
- Used "less than" instead of "+1 less than or equal."

---

Please review my suggestion.
This task depends upon

Closed by  Dan Griffiths (Ghost1227)
Monday, 19 April 2010, 03:05 GMT
Reason for closing:  Implemented
Additional comments about closing:  In [testing], great pkgbuild heftig!
Comment by Gavin Bisesi (Daenyth) - Wednesday, 14 April 2010, 17:16 GMT
Might make sense to do them as a split package perhaps?
Comment by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 17:35 GMT
No, because you would need to build twice anyway. I could give that a go, anyway.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 18:02 GMT
I will also look into replacing the fetch_runtime stuff with rsync, similar to fetch_patches.
Comment by Tobias Kieslich (tobias) - Wednesday, 14 April 2010, 19:20 GMT
The main difference between doing it rsync style and fetch_patches is the way you or me or who ever is organizing the builds. I blow away the abs or package svn dir when I'm done with packaging but I keep my $SRCDIR, aka makepkgs source cache. Hence I benefit from fetch_patches the same way makepkg benefits from stuffing sources into $SRCDIR when rebuilding packages. Now if the rsync approach can use the $SRCDIR we would get the best of both worlds, a central cache and rsyncs incremental update algorithms.

As for making the packages mutually exclusive; vim deflated is ~30MB, 9MB compressed. ~1.5 of these 9MB account for the binary, the rest is runtime. This runtime is the same between vim and gvim. So we would serve 7.5MB redundent files. That may not sound like a lot to you, but don't forget we are on the other side of things and have to provide the bandwidth.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 19:50 GMT
Updated!

Replaced fetch_runtime with a single rsync command

Added vim-both, which builds both vim and gvim
- Moved fetch_patches into this PKGBUILD

Moved fetch_runtime to build()
- Makes vim-both simpler
- The installed runtime directory becomes much cleaner,
removing lots of stuff that's non-runtime or unneeded
(e.g. macmenu.vim)
- However, manually installing logtalk.dict is neccessary
Comment by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 19:55 GMT
I see what you mean with the $srcdir cache. I'll look into this.

About the big vim runtime: Splitting the runtime into a third package in the vim-both PKGBUILD wouldn't be difficult. Should I continue developing this PKGBUILD?
Comment by Tobias Kieslich (tobias) - Wednesday, 14 April 2010, 21:16 GMT
Actually, Dan took over most of my packages while I'm on leave. My main concern is, that building vim is complex and a lot can be done wrong there. So at the moment, while the symlining seems flimsy, I think we got it right. I haven't heard about complaints or problems in a long time. Experience commands if it ain't broken so don't fix it.

As for progressing with vim packages, truth is when building vim, gvim is built right afterwards. So making use of makepkgs new split functionality makes a heapload of sense. Having everythiong done in one build, split into vim,gvim and runtime would be a good thing. At this point I would do the same as we do now -> don't bother if gvim dependent runtime stuff is in the main runtime package, just stuff it in there. Splittting those out is more error prone and so much harder to maintain than it is worth it in the terms of possible benefits. So you have my go ahead if you wanna do that. Check back with Dan, though.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 21:43 GMT
I tried to be careful building. I compared the contents of packages after changes, checked using namcap, and verified vim still runs.

Updated:

Now caching runtime in $srcdir/runtime
- See _get_runtime in the PKGBUILD

vim-both now builds a vim-runtime package
- /usr/share/vim is removed from vim and split into vim-runtime
from gvim. Inelegant, but "make installruntime" wouldn't
install the whole runtime, and I didn't want to delve deeper into
vim's build system at this time.

Dropped separate PKGBUILDs and renamed vim-both to vim

Removed vim helptag building from .install files
- Seemed to be a chunk of unmaintained code. The directory
/usr/share/vim/doc doesn't exist. The runtime already
ships with helptags, and addon packages would be using
/usr/share/vim/vimfiles/doc
- Removed vim.install
Comment by Tobias Kieslich (tobias) - Wednesday, 14 April 2010, 23:01 GMT
since I'm at work I can't look into it atm. As for the helptags building, it updates the vim help files for the installed plugins when updating vim itself IIRC.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 14 April 2010, 23:23 GMT
Is it still needed? IIRC it's not because the plugins and the vim runtime itself don't share the same helptags anymore.
Comment by Dan Griffiths (Ghost1227) - Friday, 16 April 2010, 21:02 GMT
heftig's splitpkg looks great to me! if you don't have any objections tobias, i think it's an ideal solution to the vim problem.
Comment by Tobias Kieslich (tobias) - Saturday, 17 April 2010, 18:44 GMT
yeah I just looked into it and /me likes it.

Throw it into testing.
Comment by Jan Alexander Steffens (heftig) - Sunday, 18 April 2010, 05:36 GMT
Great. :)
Thanks for accepting this.

Oh, I forgot to add a Contributor line:
Contributor: Jan "heftig" Steffens <uocll@stud.uni-karlsruhe.de>
Comment by Dan Griffiths (Ghost1227) - Sunday, 18 April 2010, 07:38 GMT
In [testing]
Comment by Kazuo Teramoto (kazuo) - Sunday, 18 April 2010, 21:34 GMT
Uhh, testing it...

But I little one, I thing that you forget the pkgdesc for package_vim, (pacman -Si vim give None as package description).
Comment by Dan Griffiths (Ghost1227) - Sunday, 18 April 2010, 21:45 GMT
Fixed in trunk, thanks

Loading...