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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
