Re: Add lang/openjdk21-bin?

[David Brownlee <abs%absd.org@localhost>]

On Mon, 3 Mar 2025 at 15:53, J. Lewis Muir <jlmuir%imca-cat.org@localhost> wrote:
>
> On 03/03, Greg Troxel wrote:
> > "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> >
> > > OK, I was unclear again.  Sorry about that.  Yes, I mean that
> > > lang/openjdk-bin just happens to be version 21, but that could change at
> > > any time.  I'm wishing for a versioned package so that I can encode in
> > > the dependency that version 21 is what's wanted.
> > >
> > > This is probably also related to me being unclear on what you
> > > pointed out in your other reply, that you generally don't specify a
> > > dependency on foo-bin, just foo.
> >
> > I suggest reading /usr/pkgsrc/mk/java-vm.mk
>
> OK, that was helpful; I see two things from that:
>
> 1. I can control which JVM is the default with PKG_JVM_DEFAULT.
> 2. PKG_JVM_DEFAULT can accept *-bin values.
>
> I understand this to mean that it would work to add lang/openjdk21-bin,
> add support for it in mk/java-vm.mk, in particular as a possible value
> for PKG_JVM_DEFAULT, and then I could set PKG_JVM_DEFAULT=openjdk21-bin
> to get the behavior I'm after.
>
> > > But this still seems like a mismatch
> > > to me in that there's openjdk<version> and openjdk-bin, but not
> > > openjdk<version>-bin.  So, if openjdk<version> doesn't build for your
> > > platform and pkgsrc was able to fall back to openjdk-bin because it was
> > > at <version>, that will break when openjdk-bin gets switched to a newer
> > > <version>.
> >
> > It would then end up with not having a bin package.
>
> Right, and that's the problem I was raising.
>
> > The overall tone of java-vm.mk is that a newer jdk is always ok.
>
> Unfortunately, that's not great.  It's true that Java is very good
> at maintaining backward compatibility, but only to a point; things
> still change.  For example, subsystems will be marked as deprecated and
> eventually removed in future versions, and if you end up getting a JVM
> version where whatever got removed, then software that used it and used
> to work will break.  Similarly for the command line interfaces of java,
> javac, javadoc, etc.  It's not that they're impossible changes to deal
> with, but they will make certain things break that you then have to fix,
> so that's why I like to stay on an LTS version for a good chunk of time
> so that I don't have to mess with fixing stuff like that quite so often.

Have just added the following to java-vm.mk

# Note: We should never choose a non LTS JDK when an LTS one is available
# (unless a user has overridden)

I know we only have LTS (and ancient :) versions in pkgsrc at the
moment, but is worth stating up front in case anyone imports a non LTS
JDK.

David