pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Add lang/openjdk21-bin?
On 03/02, Greg Troxel wrote:
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
>
> > I see lang/openjdk21, but not lang/openjdk21-bin. Is there openness to
> > adding lang/openjdk21-bin?
>
> lang/openjdk-bin is 21. So I don't understand your question.
>
> If you mean "should openjdk-bin be renamed to openjdk21-bin, so that's
> clearer?", then perhaps. If you mean "should there be all three of
> openjdk{11,17,21}-bin?" then I don't know if anybody wants them, but
> there's no doctrine against it. Just the usual if we're going to
> version, version all and don't flip back and forther.
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. 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>.
> > My use case is that I'd like to create a package that depends on Java
> > version 21 because that's the latest LTS version, and I'm nervous to
> > depend on lang/openjdk21 because it's not certified according to the
> > warning in its DESCR file that says the following:
> >
> > This package is NOT certified to be compatible with any Java standard.
> > Use at own risk.
>
> Are you working in an environment that has audits?
No...well, at least not the kind of audits that I think you mean.
Lewis
Home |
Main Index |
Thread Index |
Old Index