Clear definition of default-java and its scope

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256

Hi

In light of LP: #687263 and LP: #564699 I think it might be time for usto clearly define the purpose of default-java; not only for our own sakebut also for the sake of Java users on Debian(-based distros).

Note that by "default-java" I here refer to the symlink/usr/lib/jvm/default-java and also the default-jre{,-headless},default-jdk packages.

The current definition of default-java seems to be: - The default Java used for building Debian packages (based on how we use it) - The best free/open Java available on the platform (based on how we "choose" the default-java on a given architecture).

Users, who do not work on Debian packages, will most likely not come tothe same conclusions, since they are not involved in Debian JavaDevelopment. Particularly in the LP: #687263 case, a user expected "default-java"to be controlled by alternatives. I assume he/she read "default" as"system-default" and personally I found that a very valid assumption(from a user perspective).

I propose we solve this by explicitly defining default-java to hold thetwo definitions I mentioned above (it is the only sane choice forbackwards compatibility as far as I can tell) and post-Squeeze introducea "system-default-java", which is an alternative-controlled Java. ForSqueeze I would settle with updating the Java FAQ. This solution will not directly solve LP: #687263, but it willsolve LP: #564699 and also a part of LP: #45348 by allowing users to setJAVA_HOME to the system-default-java and now update-alternatives willautomatically update their JAVA_HOME as well.

Clear definition of default-java and its scope

Hi Niels,

On Wed, Dec 8, 2010 at 2:00 PM, Niels Thykier <ni***@*hykier.net> wrote:> I propose we solve this by explicitly defining default-java to hold the> two definitions I mentioned above (it is the only sane choice for> backwards compatibility as far as I can tell) and post-Squeeze introduce> a "system-default-java", which is an alternative-controlled Java. For> Squeeze I would settle with updating the Java FAQ.> This solution will not directly solve LP: #687263, but it will> solve LP: #564699 and also a part of LP: #45348 by allowing users to set> JAVA_HOME to the system-default-java and now update-alternatives will> automatically update their JAVA_HOME as well.

Clear definition of default-java and its scope

In light of LP: #687263 and LP: #564699 I think it might be time for usto clearly define the purpose of default-java; not only for our own sakebut also for the sake of Java users on Debian(-based distros).

Note that by "default-java" I here refer to the symlink/usr/lib/jvm/default-java and also the default-jre{,-headless},default-jdk packages.

The current definition of default-java seems to be: - The default Java used for building Debian packages (based on how we use it) - The best free/open Java available on the platform (based on how we "choose" the default-java on a given architecture).

Users, who do not work on Debian packages, will most likely not come tothe same conclusions, since they are not involved in Debian JavaDevelopment. Particularly in the LP: #687263 case, a user expected "default-java"to be controlled by alternatives. I assume he/she read "default" as"system-default" and personally I found that a very valid assumption(from a user perspective).

I propose we solve this by explicitly defining default-java to hold thetwo definitions I mentioned above (it is the only sane choice forbackwards compatibility as far as I can tell) and post-Squeeze introducea "system-default-java", which is an alternative-controlled Java. ForSqueeze I would settle with updating the Java FAQ. This solution will not directly solve LP: #687263, but it willsolve LP: #564699 and also a part of LP: #45348 by allowing users to setJAVA_HOME to the system-default-java and now update-alternatives willautomatically update their JAVA_HOME as well.No. This should not be done. Relying on an alternative for a build makesproblems much harder to debug, if you first have to find out which alternativeis actually used, and which alternative is used for the build.I am fine with improving user experience, but the change in the proposed formwill obfuscate the build process.Matthias

Clear definition of default-java and its scope

On Wed, Dec 8, 2010 at 8:52 PM, Matthias Klose <d***@*buntu.com> wrote:> No. This should not be done. Relying on an alternative for a build makes> problems much harder to debug, if you first have to find out which> alternative is actually used, and which alternative is used for the build.>> I am fine with improving user experience, but the change in the proposed> form will obfuscate the build process.

Niels did not propose to use alternatives for building packages. Hisproposal is fully backwards compatible as far as I understood it.

Clear definition of default-java and its scope

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256

On 2010-12-08 21:18, Torsten Werner wrote:> On Wed, Dec 8, 2010 at 8:52 PM, Matthias Klose <d***@*buntu.com> wrote:>> No. This should not be done. Relying on an alternative for a build makes>> problems much harder to debug, if you first have to find out which>> alternative is actually used, and which alternative is used for the build.>>>> I am fine with improving user experience, but the change in the proposed>> form will obfuscate the build process.> > Niels did not propose to use alternatives for building packages. His> proposal is fully backwards compatible as far as I understood it.> > Torsten> >

Yes, the idea is that default-java remains what it always has been forus; namely the default implementation used for building (complete withthe standard symlink).

The "change" is to introduce a new symlink as well (next to thedefault-java symlink) which is an "alternative" that by default pointsto default-java, but can be updated.