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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx <mailto:jvanek@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:jvanek@xxxxxxxxxx> <mailto:jvanek@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:jvanek@xxxxxxxxxx> <mailto:jvanek@xxxxxxxxxx> <mailto:jvanek@xxxxxxxxxx> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx <mailto:java-devel@xxxxxxxxxxxxxxxxxxxxxxx> <mailto:java-devel@xxxxxxxxxxxxxxxxxxxxxxx> >>> <mailto:java-devel@xxxxxxxxxxxxxxxxxxxxxxx> To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx <mailto:java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx> <mailto:java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx> <mailto:java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@xxxxxxxxxx <mailto:jvanek@xxxxxxxxxx> <mailto:jvanek@xxxxxxxxxx> M: +420775390109 >>> >>> -- >>> Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@xxxxxxxxxx <mailto:jvanek@xxxxxxxxxx> M: +420775390109 -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@xxxxxxxxxx M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
