Alternatives problems

[James Vega]

On 3/15/06, Pierre Habouzit <pierre.habouzit at m4x.org> wrote:
> 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.

I was originally under that impression, too, but on second look I don't think
that's the case.  Policy states that the build target need not do anything.  The
binary target would then need to call the proper build-* targets to build the
package.  build-arch/build-indep could then depend on individual binary-*
targets which would depend on the install-* target.  The changes necessary
might be fairly low impact.  It looks like changing some of the target
dependencies
from a foreach to a patsubst could do most of the work.  I don't currently have
access to my computer to fiddle around with it, though (network went down).
I'll take a better look at that and respond to your other comment when I get
home tonight.

James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at jamessan.com>