In light of LP: #687263 and LP: #564699 I think it might be time for us
to clearly define the purpose of default-java; not only for our own sake
but 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 to
the same conclusions, since they are not involved in Debian Java
Development.
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 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[1].
This solution will not directly solve LP: #687263[2], 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.
--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CFF8179.8070707@thykier.net">http://lists.debian.org/4CFF8179.8070707@thykier.net
12-08-2010, 06:38 PM
Torsten Werner
Clear definition of default-java and its scope
Hi Niels,
On Wed, Dec 8, 2010 at 2:00 PM, Niels Thykier <niels@thykier.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[1].
> *This solution will not directly solve LP: #687263[2], 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.
that is a good idea.
Cheers,
Torsten
--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=ZbG4da9=vw8cbsmnGZ2RqUhLOM9CYjbLeQnWR@mail .gmail.com">http://lists.debian.org/AANLkTi=ZbG4da9=vw8cbsmnGZ2RqUhLOM9CYjbLeQnWR@mail .gmail.com
12-08-2010, 06:52 PM
Matthias Klose
Clear definition of default-java and its scope
On 08.12.2010 14:00, Niels Thykier wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi
In light of LP: #687263 and LP: #564699 I think it might be time for us
to clearly define the purpose of default-java; not only for our own sake
but 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 to
the same conclusions, since they are not involved in Debian Java
Development.
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 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[1].
This solution will not directly solve LP: #687263[2], 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.
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.
Matthias
--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CFFE1FD.3080906@ubuntu.com">http://lists.debian.org/4CFFE1FD.3080906@ubuntu.com
12-08-2010, 07:18 PM
Torsten Werner
Clear definition of default-java and its scope
On Wed, Dec 8, 2010 at 8:52 PM, Matthias Klose <doko@ubuntu.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
--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=TA4qa=KoGPoM4r7HU-0wKOU7UQVtCtdp-14U5@mail.gmail.com">http://lists.debian.org/AANLkTi=TA4qa=KoGPoM4r7HU-0wKOU7UQVtCtdp-14U5@mail.gmail.com
12-08-2010, 08:23 PM
Niels Thykier
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 <doko@ubuntu.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 for
us; namely the default implementation used for building (complete with
the standard symlink).
The "change" is to introduce a new symlink as well (next to the
default-java symlink) which is an "alternative" that by default points
to default-java, but can be updated.
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CFFF736.6090102@thykier.net">http://lists.debian.org/4CFFF736.6090102@thykier.net
Clear definition of default-java and its scope
