[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