<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-15">
</head>
<body>
<div class="moz-cite-prefix">Am 22.02.21 um 22:05 schrieb Tim Mooney
via oi-dev:<br>
</div>
<blockquote type="cite"
cite="mid:eb7f3334-ffcd-fa0-de56-408f9d519f@ndsu.edu">In regard
to: [oi-dev] openssl and gmake REQUIRED_PACKAGES,
<a class="moz-txt-link-abbreviated" href="mailto:stes@PANDORA.BE">stes@PANDORA.BE</a>...:
<br>
<br>
There's one specific part of this I want to comment upon:
<br>
<br>
<blockquote type="cite">How were the upgrades of openssl done in
the past ?
<br>
<br>
Isn't the easiest way to use the old strategy from the past to
upgrade openssl,
<br>
and then (without mediator I suppose) upgrade all packages to
the new openssl ?
<br>
</blockquote>
<br>
No, the new strategy is (in my opinion) a huge improvement over
the old
<br>
strategy.
<br>
<br>
Because of the huge list of packages that depend upon openssl, in
the
<br>
past when there was a breaking ABI change in openssl, the only way
to
<br>
upgrade was to undertake a massive effort to upgrade openssl + all
<br>
dependencies at once. It was a huge barrier for all but the most
<br>
experienced packagers. I looked at updating openssl last year and
once
<br>
I saw what was involved, I gave up and went on to other tasks.
<br>
<br>
With the new mediator-based approach, it's much easier to upgrade
<br>
dependencies in smaller chunks. It also puts us in a better place
for
<br>
when OpenSSL 3.0 is released, as packages can be migrated to that
slowly
<br>
over time while both 1.1.x and 3.0.x are supported.
<br>
<br>
I hope that a few other libraries with huge dependencies (I'm
looking at
<br>
you, library/icu) can eventually be converted to the mediator
approach.
<br>
It makes it possible to move dependencies to a new version in
phases,
<br>
rather than having to do it all at once.
<br>
<br>
I'm very thankful that Aurélien made this improvement to our
<br>
openssl package.
<br>
<br>
Tim
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
oi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a>
<a class="moz-txt-link-freetext" href="https://openindiana.org/mailman/listinfo/oi-dev">https://openindiana.org/mailman/listinfo/oi-dev</a>
</pre>
</blockquote>
Alas the situation is a little bit more complex. The
mediator-approach helps with it but we still have a lot of work.<br>
- First, we have a few packages that adhere to what USE_OPENSSL11
and openssl's pkgconfig files tell them.<br>
These packages can be converted easily by incrementing the
COMPONENT_REVISION, setting USE_OPENSSL11=yes,<br>
and run gmake publish to update the package's pkg5 file.<br>
Some of these packages have already been merged.<br>
<br>
- Then we have the majority of packages that also need the mediator
version of openssl set to 1.1 (on our build server AND on all client
machines) to work properly.<br>
This happens when the package's configuration system ignores
(partially) openssl's pkgconfig settings, eg. for libcrypto
pkgconfig looks like this:<br>
prefix=/usr/openssl/1.1<br>
exec_prefix=${prefix}<br>
libdir=${exec_prefix}/lib/<br>
includedir=${prefix}/include<br>
enginesdir=${libdir}/engines-1.1<br>
<br>
If libdir is being ignored the mediator version settings come into
place, which is the case for the majority of all packages.<br>
(I have learned recently that the mediator approach is neither
suitable nor intended for mediating .so files the way we would
need.)<br>
<br>
- We also have some packages that don't like openssl-1.1 at all
(most of them are outdated) and need additional work.<br>
- We also have some more packages with all kinds of different
problems, like linking against openssl version 1.1 and 1.0.0
simultaneously.<br>
<br>
The bulk merge of most of the updated packages is necessary because
we have lots of packages with multiple indirect dependencies on
openssl (eg. other libraries).<br>
Thus, we cannot (should not) update at different times because that
will likely create problems.<br>
<br>
Andreas<br>
<br>
</body>
</html>