Alternatives problems

[Pierre Habouzit]

Le Mer 15 Mars 2006 05:42, James Vega a écrit :
> 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).

why can't we have the man pages somewhere in /usr/share/vim/manpages/ 
and be linked from $MAH_PATH iff a vim-variant is installed ?

> 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

AFAICT it is against policy.

> 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

-- 
·O·  Pierre Habouzit
··O                                                madcoder at debian.org
OOO                                                http://www.madism.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20060315/78eab0de/attachment.pgp