On Fri, 11 Nov 2022, Emmanuel Bourg wrote:
> once the system
> is upgraded to bookworm, openjdk-11-jre will not be updated anymore and a
> manual update to openjdk-17-jre will be necessary at some point.
Yes, but if this is precisely the desired outcome…
> Why worse? sid users will be the first
Le 11/11/2022 à 01:46, Thorsten Glaser a écrit :
3. openjdk-11-jre-headless was used in bullseye (most people I know
do this to avoid the needless metapackage), the user will end up with
both because the Provides on java-runtime-headless in bullseye was
unversioned but maybe they don’t (worse if
On Fri, 11 Nov 2022, Emmanuel Bourg wrote:
> default-jre-headless | java11-runtime-headless
>
> Let's assume this is changed in bookworm to:
>
> default-jre-headless | java-runtime-headless (>= 11)
>
> Considering a tomcat9 user upgrading from bullseye to bookworm, there are two
> cases
Le 10/11/2022 à 22:39, Thorsten Glaser a écrit :
That’s not the point. That much is true, but the point here is
that the user *CAN* use Java 11, *if* they have installed it
beforehand, i.e. that they are not _forced_ to upgrade.
If they don’t have it installed, the default-jre will be installed
Le 10/11/2022 à 22:15, Thorsten Glaser a écrit :
The application defines
default-jre (>= 2:1.11) | java-runtime (>= 11)
but openjdk-11-jre does not yet Provides java-runtime,
only java11-runtime. This will force the user to 17.
But openjdk-17-jre also provides java11-runtime. So even
On Thu, 10 Nov 2022, Emmanuel Bourg wrote:
> But openjdk-17-jre also provides java11-runtime. So even with:
>
> default-jre (>= 2:1.11) | java11-runtime
>
> there is no guarantee Java 11 will be used.
That’s not the point. That much is true, but the point here is
that the user *CAN* use Jav
On Thu, 10 Nov 2022, Emmanuel Bourg wrote:
> better. But I don't see the need to wait a decade before using the versioned
> java-runtime dependency in the packaged applications, what issue do you
> foresee?
The application defines
default-jre (>= 2:1.11) | java-runtime (>= 11)
but openj
Le 31/10/2022 à 19:54, Thorsten Glaser a écrit :
No, we really should not: the various JDKs also only provide
java-runtime and this dependency is specifically meant to
also make it possible for software to use a JRE *other* than
the default (the dependency reads like
default-jre (>= x) |
Le 08/11/2022 à 20:49, Moritz Mühlenhoff a écrit :
If the Security Team agrees I think we should continue with this strategy in
Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The first OpenJDK 21
EA release will be available in December well before the freeze in March, so
that fits with
On Tuesday, 8 November 2022 19:51:12 GMT Moritz Mühlenhoff wrote:
> Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:
> > > Last point, we still have OpenJDK 8 in unstable to help with the
> > > bootstrapping of some packages that can't build directly with the
> > > latest JDK (more
On Tue, 8 Nov 2022, Moritz Mühlenhoff wrote:
> Do we even have to keep 8 around in unstable at this point? If people
> want to bootstrap kotlin or scala for a new arch, why can't this
> happen on a buster system?
AIUI this is not a :any issue, but an issue of bootstrapping one
new enough to run w
Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:
> > Last point, we still have OpenJDK 8 in unstable to help with the
> > bootstrapping
> > of some packages that can't build directly with the latest JDK (more
> > specifically, Kotlin and Scala). Similarly I think we should preserv
Am Thu, Sep 29, 2022 at 12:00:42PM +0200 schrieb Emmanuel Bourg:
> Hi all,
Sorry for the late reply, this got backlogged in my inbox.
> The first point is to plan when we'll switch the default JDK to OpenJDK 17.
> The transition has progressed well, with 113 bugs fixed already, but there
> are st
On Mon, 31 Oct 2022, Emmanuel Bourg wrote:
> Also worth noting, default-jre now provides a versioned java-runtime
> dependency. This means we can now replace the java-runtime dependencies
> with java-runtime (>= n).
No, we really should not: the various JDKs also only provide
java-runtime and thi
Le 29/09/2022 à 12:00, Emmanuel Bourg a écrit :
I propose to switch on October 31th
for Halloween, such that the switch will unleash compatibility
nightmares and runtime horrors haunting those who have ignored the bug
reports for months ;)
As announced last month, I've just uploaded java-com
On Thu, Sep 29, 2022 at 08:07:30PM +0200, Emmanuel Bourg wrote:
> Le 29/09/2022 à 14:06, Thorsten Glaser a écrit :
>
> > > Last point, we still have OpenJDK 8 in unstable to help with the
> > > bootstrapping
> > > of some packages that can't build directly with the latest JDK (more
> > > specific
On Thu, 29 Sep 2022, Emmanuel Bourg wrote:
> > Who’s going to maintain that?
>
> I don't think the maintenance is a concern, we only have to ensure it
> keeps building in sid.
Yeah well, that’s maintenance, and that was missing for 8 as shown in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug
Le 29/09/2022 à 14:06, Thorsten Glaser a écrit :
Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping
of some packages that can't build directly with the latest JDK (more
specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK
11 in unstable after
On Thu, 29 Sep 2022, Emmanuel Bourg wrote:
> previous releases is kept. This scenario is likely to continue in the future
> since the Debian and Java releases are now synchronized on the same 2 years
> cycle.
We could always delay Debian’s… (SCNR) or petition upstream to change theirs.
> Assumin
19 matches
Mail list logo
