On Friday 08 August 2003 15:31, Matt Zimmerman wrote:On Fri, Aug 08, 2003 at 03:26:34PM +0200, Egon Willighagen wrote: > Right... and I understood from Hein's email that the sablevm package > does this upon upgrade... > > Is that a bug? If sablevm does something to reset a manually selected alternative, then yes, that is a serious bug. I have not checked whether this is true.I've just had a look at sablevm's postinst... which installs the update- alternative entry for java... and it does not seem to do this...(so no bug): update-alternatives \ --install /usr/bin/java java /usr/bin/java-sablevm 350 \ --slave $man/java.1.gz java.1.gz $man/java-sablevm.1.gz
I just checked the prerm script of both sablevm and gij, and found the following comment in the sablevm script:
case "$1" in
remove|deconfigure)
update-alternatives --remove java /usr/bin/java-sablevm
;;
upgrade)
;; # I don't want to --remove the alternative during upgrade
because
# it will switch to auto and won't be set back when upgrade is
done
failed-upgrade)
;;
*)
echo "prerm called with unknown argument \`$1'" >&2
exit 1
;;
esac
As you can see the --remove option will set it back to auto. So the
problem is not with sablevm, as the gij 'prerm' script (see below) does in
fact do a --remove also in the case of upgrade, and thus the resulting
behavior of reverting to auto mode.
update-alternatives --remove java /usr/bin/gij-wrapper-3.3 >/dev/null 2>&1 || true Should I report this as a bug in gij, or is this a problem with update- alternatives? I mean, why should removing an alternative cause it to revert to auto mode, unless the alternative being removed is the default alternative?
So I guess appologies to the sablevm maintainer is in order. - Hein