Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2022-05-26 at 14:07 -0400, Solomon Peachy wrote:
> On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote:
> > I am not talking about FLOSS vs non FLOSS, that's obvious. But
> > bundled libs
> > and properly tested / certified vs dynamic linking and less testing
> > / no
> > certification.
> 
> I've been following this circular thread from the outset (And I do
> make 
> use of Fedora's JDK packages), but one thing I don't recall seeing is
> a 
> specific (or even general) example of the sort of failures/problems
> that 
> have come from linking against system libraries vs just using the 
> bundled ones.
> 
> Relatedly, I think it would also be very valuable to know if these 
> problems are mostly one-off (eg a major release of the jdk or
> dependent 
> library lands in rawhide and breakage ensues), or occur throughout a 
> specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a
> critical 
> security update which leads to a failure to pass TCK, or quarterly 
> java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to
> fedora's 
> bundled library libfoo version)
> 
I don't think that was the gist of it. I believe that it relates to the
numbers of OpenJDK we carry, and the difficulty faced by the packagers
of that to comply with packaging in Fedora's ecosystem when doing it.
Libraries are bundled into jars not the source, etc... this all
snowballs across what 4 version now supported? I don't remeber reading
about unspecified TCK failures, just the workload as a result of our
packaging requirements.

> I mean, it's been strongly implied (if not outright stated) that 
> resolving these unspecified TCK failures, caused by using non-bundled
> libraries, is the real burden, not the act of running the TCK for
> each 
> build -- but is the TCK (or upstream JDK) really that _brittle_?
> 
I built Netbeans for F36 Silverblue and when building it from source,
it still uses maven repo to download binary tools (maven plugin's) to
build with, this would be in violation of the packaging guidelines I
think. So to package it I would need to also package all of those
plugin's along side to support it in the Fedora Project ecosystem, just
for the actual build process.

Regards,
Stephen Snow
>  - Solomon
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux