Alternatives problems
Pierre Habouzit
pierre.habouzit at m4x.org
Wed Mar 15 08:30:41 UTC 2006
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
More information about the pkg-vim-maintainers
mailing list