SPECS (AC-branch): vim.spec - updated to 7.1.305 - php.vim updated to 0.9.7...

wrobell wrobell at pld-linux.org
Fri May 30 17:35:21 CEST 2008


On Fri, May 30, 2008 at 05:29:06PM +0200, Jakub Bogusz wrote:
> On Fri, May 30, 2008 at 09:19:20AM +0200, Adam Gołębiowski wrote:
> > On Fri, May 30, 2008 at 09:36:23AM +0300, Elan Ruusamäe wrote:
> > > On Friday 30 May 2008 01:20, adamg wrote:
> > > > - vim-heavy / gvim-heavy subpackages (todo done)
> > > 
> > > should we perhaps package vim from vim package as vim.ncurses and make symlink 
> > > to vim and then one can replace the symlink with heavy manually? so it's done 
> > > line in gvim packages.
> > > 
> > > or should we perhaps also overwrite symlink with first vim-heavy install (and 
> > > restore if uninstalled)?
> > 
> > +1 for packaging vim as vim.ncurses (and perhaps separate vim-ncurses
> > package).
> > 
> > I was thinking with something like simple vim-config shell script. When
> > vim/vim-heavy is installed, it checks for /usr/bin/vim existence and
> > creates such symlink when necessary. When the other package gets
> > installed, it does nothing, as /usr/bin/vim already exists.
> > 
> > And for those upgrading older vim versions, vim package would create
> > /usr/bin/vim -> /usr/bin/vim.ncurses symlink.
> > 
> > Sample vim-config usage (idea borrowed from various gentoo's *-config
> > scripts):
> > 
> > # vim-config --list
> >   [1] /usr/bin/vim.ncurses *
> >   [2] /usr/bin/vim.heavy
> > # ls -l /usr/bin/vim
> > lrwxrwxrwx 1 root root 8 2008-04-09 21:57 /usr/bin/vim -> vim.ncurses*
> > # vim-config --select 2
> > # vim-config --list
> >   [1] /usr/bin/vim.ncurses
> >   [2] /usr/bin/vim.heavy *
> > # ls -l /usr/bin/vim
> > lrwxrwxrwx 1 root root 8 2008-04-09 21:57 /usr/bin/vim -> vim.heavy*
> > 
> > And similar gvim-config script for gvim. {,g}vim-config would be part of
> > vim-rt.
> 
> Uhm, looks like etc-alternatives specialization.
> So maybe use more general solution instead of individual scripts in
> dozen packages (I bet vim and gvim won't be the only ones, e.g. pinentry
> is good candidate for the next)?

speaking about pinentry :) it behaves really nice. it starts GUI version
if DISPLAY is set and curses version when DISPLAY is not set :) still
probably something needed to solve qt/gtk preference i believe :)

[...]

    wrobell <wrobell at pld-linux.org>


More information about the pld-devel-en mailing list