[Pkg-octave-devel] Re: update-alternatives and Octave packages

Rafael Laboissiere rafael at debian.org
Fri Feb 10 08:04:12 UTC 2006


* John W. Eaton <jwe at bevo.che.wisc.edu> [2006-02-09 17:18]:

> Since the octave2.*-headers packages depend on the corresponding
> octave2.* packages, it seems to me that any alternatives in the
> headers packages should be "slaves" of the primary package (octave in
> this case).  But no, I don't see a convienent way to manage that since
> the --slave option for update-alternatives seems to be tied to the
> --install option.  What we seem to need is a way to say that something
> (the octave binary?) is the "master" object here, and that all the
> other scripts, links to include files, etc., no matter what package
> they come from, are "slave" objects for update-alternatives.  The idea
> is to make it possible for someone to switch from one version of
> "octave" to another, without having to know about all these other
> programs or dependent packages.  If that is not currently possible
> with update-alternatives, could we extend the functionality so that it
> is possible?  Or is that hard to do, and we should find some other way
> to deal with this problem ourselves?

It might be possible to write a script (called, say, 
/usr/bin/octave-update-alternatives) which will be called from the
postinst scripts of both octave2.* and octave2.*-headers packages.  This
script would install the alternatives with the appropriate slave links
according to the presence or absence of the octave2.*-headers in the
system.  I have not yet tested this idea, though, so I do not know if it
really works.  I will give a try next week, unless someone else beats me
on that.

> Do no other packages face similar problems?

To the best of my knowledge, no.  However, I cannot pretend I know
everything about the >15000 packages in Debian...

We could ask this at debian-devel.

-- 
Rafael



More information about the Pkg-octave-devel mailing list