On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote:
> Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge:
> > Actually the patch has already been applied to openjdk13, if I am not
> > mistaken. So I do not understand how the source could be built in master
> > then, while the exact same code (?!) fails on core-updates...
> 
> Well, there is a somewhat hidden difference.
> core-updates introduces
>                         "openjdk-10-hotspot-pointer-comparison.patch"
>                         "openjdk-10-hotspot-stack-size.patch"
> to openjdk10.
> 
> openjdk11 is a package of its own without the patch.
> 
> openjdk12 uses the newly defined make-openjdk to start from openjdk11,
> overwriting the source together with openjdk-10-hotspot-stack-size.patch
> in core-updates, and without the patch in master. (And it uses an obscure
> tarball instead of a git checkout - why?)
> 
> openjdk13 has the same code in core-updates and master:
> (define-public openjdk13
>   (make-openjdk openjdk12 "13.0.13"
>                 "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"))
> So in core-updates it inherits the patch from openjdk12, in master
> it does not (I think). And then I suppose it passes the patch on to all
> its descendants.

It's definitely possible that the master->core-updates merge messed with
the package definitions and the inheritance and I didn't notice it.

> The following seems to work and create source for openjdk13 and later:
> (define-public openjdk13
>   (make-openjdk openjdk12 "13.0.13"
>                 "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
>   (source (origin
>             (inherit (package-source base))
>             (patches '())))))
> 
> Okay to push if I manage to build current openjdk with it?

Yeah, that's probably fine.

> Is it necessary to keep all these version of openjdk and to bootstrap
> version n with version n-1?

Probably? I assume if you can cut some out that'd be ok. I'm pretty sure
openjdk-11 and openjdk-17 are considered LTS by upstream so it would
make sense to keep those specifically.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted