update-java-alternatives in postinst
On 2011-11-07 15:39, Florian Weimer wrote:
> Why is update-java-alternatives not used in the postinst script of Java
> implementations? I guess it's because there is no way to invoke in such
> that it makes the required adjustments, and only those. Would it make
> sense to enhance update-java-alternatives to install new alternatives,
> without switching between manual and automatic mode?
Presumably because it does not have the same level of sophistication as
update-alternatives. As I see it, it is an "admin"/"end-user" tool to
simplify choosing a java alternative and (looking at the code) I doubt
it satisfies policy requirements for a postinst code (as you mentioned).
Not to mention that java-common is not essential (and it shouldn't be),
so it cannot be relied on in (i.e.) preinst. Thus a maintainer have to
use update-alternatives directly anyway in some cases (look at the
migration code in openjdk-6-jre-headless.preinst for instance).
But what would you hope to achieve by making update-java-alternatives
usable in postinst? What does it do that the current maintainer scripts
cannot (or are not) do(ing) with update-alternatives?
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com