Re: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements

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

 



Zbigniew Jędrzejewski-Szmek wrote:
> That's part of what makes it hard to discuss things with you:
> the proposal _explicitly_ says that only some libraries will be bundled.
> (There's a separate section about this!)
> So it's not "all-bundled" but "some of the low-level libs are bundled".

I am sorry, but I have to think that you are the one weasel-wording. The 
proposal says in its subject that it wants to "Build all JDKs in Fedora 
against in-tree libraries". Not "some in-tree libraries", just (unqualified) 
"in-tree libraries", which in correct English defaults to meaning "all in-
tree libraries that are available". (This may actually be a grammar error 
from the submitters, in which case that should have been fixed before voting 
on the proposal.)

In the full text, the proposal includes the following list:
> --with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled"
> --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled"
> --with-harfbuzz="bundled"
It does not state whether these are all the libraries that upstream bundles 
in the tree or, if not, which ones will not be bundled. (So I cannot tell 
from the proposal's text whether the "all-bundled" term I used is an 
exaggeration or not.) It also does not state why these libraries in 
particular were selected to be bundled.

I also do not see these libraries as being particularly "low-level", though 
anyway, IMHO, the lower-level a library, the worse an idea it is to bundle 
it. (E.g., trying to bundle glibc would be a horrible idea, but that is not 
what is being proposed here anyway. So I am not sure why you chose the word 
"low-level".)

In addition to the libraries that will be bundled, there is also the switch 
to statically linking the system libstdc++, which is IMHO an entirely 
different change, and for which I do not see any possible benefit at all, 
since we will be using the exact same version of libstdc++ as before, just 
without the benefits of shared libraries.

> The package is still build by Fedora maitainers, from controlled sources,
> on Fedora infra. The only difference is that some libraries are in a
> version that the upstream project has blessed.

Instead of the version that the distribution has blessed, that is known to 
work together with all the other software in the distribution, and that does 
not require extra space for Java only.

> The upstream project is big and has an extensive test suite and cares
> about vulnerabilities as much as we do.

But introducing a middleman (who needs to upgrade the bundled library and 
issue a security update for Java that we need to package, instead of 
directly packaging the upgraded library) necessarily increases the response 
time to security vulnerabilities.

> You describe it as if the bundling would radically change things, but I
> think that in this case the impact for users will not be noticable.

The mailing list discussion had pointed out at least one user-visible issue, 
related to fontconfig support.

And the increased disk space and RAM requirements will definitely be 
noticeable.

        Kevin Kofler
_______________________________________________
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