You are most certainly welcome.
Stephen Snow
On Tue, Dec 8, 2020 at 10:55, Jiri Vanek <jvanek(a)redhat.com> wrote:
Thanx!
I was not aware of this effort.
Thank you a lot for sharing!
J.
On 12/7/20 6:29 PM, Stephen Snow wrote:
> Hello,
> I think this is the pertinent upstream issue
> <
https://github.com/fedora-sysv/chkconfig/issues/9>
>
> On Mon, Dec 7, 2020 at 12:03, Stephen Snow <s40w5s(a)gmail.com
> <mailto:s40w5s@gmail.com>> wrote:
>> Sorry, I don't seem to be able to locate it now. I'll keep
>> searching and update you later once I find or don't find anything.
>>
>> On Mon, Dec 7, 2020 at 17:51, Jiri Vanek <jvanek(a)redhat.com
>> <mailto:jvanek@redhat.com>> wrote:
>>> On 12/7/20 5:29 PM, Stephen Snow wrote:
>>>
>>> That sounds reasonable, I watched the probelms last time from
>>> afar, and didn't envy you.
>>>
>>> 90% of most terrible work was done by Fabio. All kudos to him!-)
>>>
>>> As for alternatives not working in SB or FCOS, I filed a bug
>>> against SB, which was closed since there was an upstream bug
>>> tracking it. AFAIK, it will be tackled at a later release. Though
>>> I am uncertain what later release is the intended target. In the
>>>
>>> I see. Definitely not in next jdk version. Although I recall this
>>> issue a bit do you ave the bug id handy? meantime, I am embracing
>>> the container workflow more, this includes with my jdk dev
>>> projects. As I learn this way more, it does become easier. I guess
>>> I should expect a learning curve when I want to use near bleeding
>>> edge stuff. Also, the maturing of things like flatpaks, podman,
>>> etc... is happening constantly and thus things integrate better.
>>> Plus, platforms like Quarkus have gone a long way to making this
>>> container based workflow an easier transition than it would be
>>> without. You are right. Quarkus is fresh air in this area. Jdk
>>> packaging as is now is not exactly healthy for container/flatpak
>>> world. The only reasonable way is to have base images per JDK:(
>>> Thanx a lto for ideas! J.
>>>
>>> Regards, Stephen On Mon, Dec 7, 2020 at 17:15, Jiri Vanek
>>> <jvanek(a)redhat.com <mailto:jvanek@redhat.com>
>>> <<mailto:jvanek@redhat.com>>> wrote:
>>>
>>> On 12/7/20 5:12 PM, Stephen Snow wrote: Hello Jiri, I am
>>> not a packager for Fedora, but I am a user (of Fedora) who
>>> develops in Java at times. I assume you are referring to a
>>> replacement for alternatives (which doesn't work on Silverblue or
>>> Fedora CoreOS). The ability to switch between different JDK No!
>>> Not At all! Alternatives are remaining same. This change is
>>> solemnly for build-time only. When we were bumping jdk form 8 to
>>> 11. 50% of chanes was to edit source/target flags of javac. I
>>> would like to avoid it in future.. versions is a must for anyone
>>> doing Java programming for different organizations. So anything to
>>> make that a smoother operating workflow IMHO is welcome. Hm. How
>>> come alternatives do not work for SilverBlue and CoreOs? Stephen
>>> Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek <jvanek(a)redhat.com
>>> <mailto:jvanek@redhat.com> <<mailto:jvanek@redhat.com>>
>>> <<mailto:jvanek@redhat.com>>> wrote: Hi! I had risen this
topic
>>> during jdk11 bump. but it somehow get lost. The idea is, to
>>> provide rpm
>>> macros, keeping the default source/target eventually -
>>> for jdk11 and up -the release - numbers for javac to use. Then to
>>> provide tooling, which will help packagers to use them - for ant
>>> and maven it should be simple. For others, probably nothing to do
>>> on our side, each packager will be able to patch/sed theirs builds
>>> as necessary (Still it will help a lot for future). I do not know
>>> how to provide them as default (except hardcoding in xmvn, and
>>> only allow to disable them on demand). This will smooth the bump
>>> to jdk17 in f36 really a lot. Thoughts? J. -- Jiri Vanek Senior QE
>>> engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek(a)redhat.com
>>> <mailto:jvanek@redhat.com> <<mailto:jvanek@redhat.com>>
>>> <<mailto:jvanek@redhat.com>>
<<mailto:jvanek@redhat.com>> M:
>>> +420775390109 _______________________________________________
>>> java-devel mailing list -- java-devel(a)lists.fedoraproject.org
>>> <mailto:java-devel@lists.fedoraproject.org>
>>> <<mailto:java-devel@lists.fedoraproject.org>>
>>> <<mailto:java-devel@lists.fedoraproject.org>>
>>> <<mailto:java-devel@lists.fedoraproject.org>> To
>>> unsubscribe send an email to
>>> java-devel-leave(a)lists.fedoraproject.org
>>> <mailto:java-devel-leave@lists.fedoraproject.org>
>>> <<mailto:java-devel-leave@lists.fedoraproject.org>>
>>> <<mailto:java-devel-leave@lists.fedoraproject.org>>
>>> <<mailto:java-devel-leave@lists.fedoraproject.org>> Fedora Code
of
>>> Conduct:
>>> <
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>>> List Guidelines:
>>> <
https://fedoraproject.org/wiki/Mailing_list_guidelines> List
>>> Archives:
>>>
<
https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproj...
>>> -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat
>>> Czech jvanek(a)redhat.com <mailto:jvanek@redhat.com>
>>> <<mailto:jvanek@redhat.com>>
<<mailto:jvanek@redhat.com>> M:
>>> +420775390109
>>>
>>> --
>>> Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat
>>> Czech jvanek(a)redhat.com <mailto:jvanek@redhat.com>
>>> <<mailto:jvanek@redhat.com>> M: +420775390109
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com <mailto:jvanek@redhat.com> M: +420775390109