13

I have to use Ubuntu 10.04 at work, and can't upgrade it. I'm using Vim/gVim 7.2.

I want to upgrade it to 7.3 (with Python and Ruby extension support). Which is the best way? Add an entry in sources.lists and install a 7.3 vim/gvim package from it, or build from source? What disadvantages would I have from each approach?

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Somebody still uses you MS-DOS
  • 4,775

2 Answers2

14

The first place to check is if there's a backport, but there isn't, which isn't surprising since maverick has vim 7.2 too.

The next thing to try is if someone's put up a repository with vim 7.3 packages somewhere, preferably a PPA. There are many PPAs with vim, including several with 7.3 (not an exhaustive list).

If you don't find a binary package anywhere or don't like the ones you find, the next easiest step is to grab the source package from natty, which has vim 7.3. Download the source package (.dsc, .debian.tar.gz and .orig.tar.gz), then run

apt-get install build-essential fakeroot
apt-get build-dep vim
dpkg-source -x vim_7.3.035+hg~8fdc12103333-1ubuntu2.dsc
cd vim-7.3.035+hg~8fdc12103333
# Edit debian/changelog to add an entry with your name and “recompiled for lucid”
dpkg-buildpackage -rfakeroot -us -uc -b -nc

If all goes well, you'll have binary packages for your distributions. If you run into missing dependencies or compilation errors, this has to be solved on a case-by-case basis.

The next thing to try is to compile the upstream 7.3 source with the packaging from your Ubuntu version. This gives you a nice and clean package, but it's a little more involved, so if you don't feel confident in doing this without instructions I recommend you just compile the upstream source.

If you end up compiling the upstream source, by default, you'll end up with the files under /usr/local, and it won't be easy to uninstall them, or even to know what you have. Whenever you install something without using the package manager, I recommend installing into a separate directory structure and creating symbolic links in /usr/local (or ~/usr or whatever). Stow is nice for that:

  • Install under /usr/local/stow (or ~/usr/stow or wherever). With many programs, you can use something like ./configure --prefix=/usr/local/stow/vim-7.3. This will put the main binary at /usr/local/stow/vim-7.3/bin, and so on.
  • Run stow vim-7.3 from the /usr/local/stow directory. This creates symbolic links in the “normal” directories, e.g. /usr/local/bin/vim -> ../../stow/vim-7.3/bin/vim.
  • If you ever want to uninstall this program, just run stow -D vim-7.3 to remove the symbolic links, and delete /usr/local/stow/vim-7.3.

There is also xstow which is a similar, but more powerful programs (one of its benefits is that it can deal with conflicts).

Gilles 'SO- stop being evil'
  • 829,060
  • I've never done something like creating specific binary package for my distribution. If I compile the upstream source into /usr/local, can I just exclude it after if something goes wrong? I've never done something like this before, because I'm afraid of breaking other packages (I've done this mess before with ubuntu 8.04 here, all my python installations were just f***ed up) – Somebody still uses you MS-DOS Dec 21 '10 at 21:08
  • 2
    @Somebody: The advantage of installing a package (created by you or someone else) is that you can uninstall it easily. If you do compile the package, I recommend using (x)stow. – Gilles 'SO- stop being evil' Dec 21 '10 at 21:26
  • 3
    +1. How have I never seen stow before? It looks fantastically useful. – Steven D Dec 21 '10 at 22:07
  • Thanks, this worked like a charm in Ubuntu 10.10 with the 2:7.3.035+hg~8fdc12103333-1ubuntu7 sources from your natty link! I just had to apt-get install python3-dev. Btw. for all who are wondering, you can install the debs using sudo dpkg -i *.deb and maybe remove the vim7.2 packages before. – Juve Mar 29 '12 at 05:19
  • The only problem I see is that you need to set the vim runtimepath to not be the /usr/local/stow/vim-7.3/share/vim directory but rather something like /usr/local/share/vim directory. I think you can do that with --with-global-runtimepath=/usr/local/share/vim but I could be wrong. – docwhat Apr 18 '12 at 14:00
  • @TheDoctorWhat Good point, but setting the runtimepath is only necessary if you have third-party files to put there, which most people don't. Admittedly, people who compile the latest version are more likely to have these than average. – Gilles 'SO- stop being evil' Apr 18 '12 at 18:07
  • Another alternative is to use ./configure --prefix=/usr/local && make && make install prefix=/usr/local/stow/vim-7.3 – docwhat Apr 19 '12 at 21:43
3

Build from source. It will be quicker. Trying to both find and enable a repository for a one-off install like that will just cause you headaches further down the line.

ixtmixilix
  • 13,230
  • 4
    No, getting a repository (when there is one) is quicker. Building a package is not necessarily quicker, but for programs with many compilation options (vim is one) getting the build steps of the distribution is recommended, because it is far more likely to give you a configuration you're comfortable with. Building a package is also a major win if you want to install on multiple machines. – Gilles 'SO- stop being evil' Dec 21 '10 at 20:12