Alternatives problems

James Vega jamessan at jamessan.com
Wed Mar 15 04:42:16 UTC 2006


On Tue, Mar 14, 2006 at 10:33:52PM -0500, James Vega wrote:
> Suddenly we have no vi alternative and thus no vi(1)!  This can be
> solved fairly easily, but it will add a lot of clutter to
> /etc/alternatives.  The quick solution is to have the alternatives point
> to vim.$variant instead of the vim alternative and to have the slave
> names be $alternative.$variant.1.gz (e.g., vi.perl.1.gz) so that they
> are unique for each program for which we have alternatives.

Actually, this doesn't solve the problem because
/usr/share/man/man1/vi.1.gz is still being created by the alternative.
If the alternative is removed, it will remove
/usr/share/man/man1/vi.1.gz even though another alternative is pointing
at it.

> This is
> only slightly ugly with the vim6 package, but it comes much more so with
> vim7 because we have 9 manpage slaves for each alternative that is
> installed.
> 
> Another possibility would be to move the manpages into each variant
> package and name them after the binary being installed (e.g., vim-perl
> would have /usr/bin/vim.perl and /usr/share/man/man1/vim.perl.1.gz).
> Then each variant would have distinct files pointed at by the
> alternatives and they would be maintained properly.  The downside to
> this is that multiple copies of the same manpages would be installed.

To expand on this, we could instead install manpage symlinks or manpages
that source the real manpage (vi.perl.1.gz -> vim.perl.1.gz) and then
have the alternatives point to these (vi.1.gz -> vi.perl.1.gz).

If specifying --with-{ex,vim,view}-name to Vim's configure also renamed
the manpages accordingly, that would be a nice start.  That'd put less
work on us.  Although, I'm not sure how easily we could build packages
from that.  We'd definitely have to change debian/rules since we
currently clean up in each package's configure stage which would remove
the files we need.  This is where it would be nice to have the build
process work like:

  build-vim-gtk -> install-vim-gtk -> build-vim-perl -> install-vim-perl

instead of having all of the building done first and then the installing
of the files into their proper directories.  This is something I could
look into doing.

> Comments/suggestions?

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at jamessan.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 199 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20060314/2871117f/attachment.pgp


More information about the pkg-vim-maintainers mailing list