[oi-dev] openssl and gmake REQUIRED_PACKAGES

Andreas Wacknitz A.Wacknitz at gmx.de
Mon Feb 22 21:29:49 UTC 2021


Am 22.02.21 um 22:05 schrieb Tim Mooney via oi-dev:
> In regard to: [oi-dev] openssl and gmake REQUIRED_PACKAGES,
> stes at PANDORA.BE...:
>
> There's one specific part of this I want to comment upon:
>
>> How were the upgrades of openssl done in the past ?
>>
>> Isn't the easiest way to use the old strategy from the past to
>> upgrade openssl,
>> and then (without mediator I suppose) upgrade all packages to the new
>> openssl ?
>
> No, the new strategy is (in my opinion) a huge improvement over the old
> strategy.
>
> Because of the huge list of packages that depend upon openssl, in the
> past when there was a breaking ABI change in openssl, the only way to
> upgrade was to undertake a massive effort to upgrade openssl + all
> dependencies at once.  It was a huge barrier for all but the most
> experienced packagers.  I looked at updating openssl last year and once
> I saw what was involved, I gave up and went on to other tasks.
>
> With the new mediator-based approach, it's much easier to upgrade
> dependencies in smaller chunks.  It also puts us in a better place for
> when OpenSSL 3.0 is released, as packages can be migrated to that slowly
> over time while both 1.1.x and 3.0.x are supported.
>
> I hope that a few other libraries with huge dependencies (I'm looking at
> you, library/icu) can eventually be converted to the mediator approach.
> It makes it possible to move dependencies to a new version in phases,
> rather than having to do it all at once.
>
> I'm very thankful that Aurélien made this improvement to our
> openssl package.
>
> Tim
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
Alas the situation is a little bit more complex. The mediator-approach
helps with it but we still have a lot of work.
- First, we have a few packages that adhere to what USE_OPENSSL11 and
openssl's pkgconfig files tell them.
These packages can be converted easily by incrementing the
COMPONENT_REVISION, setting USE_OPENSSL11=yes,
and run gmake publish to update the package's pkg5 file.
Some of these packages have already been merged.

- 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.
This happens when the package's configuration system ignores (partially)
openssl's pkgconfig settings, eg. for libcrypto pkgconfig looks like this:
prefix=/usr/openssl/1.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/
includedir=${prefix}/include
enginesdir=${libdir}/engines-1.1

If libdir is being ignored the mediator version settings come into
place, which is the case for the majority of all packages.
(I have learned recently that the mediator approach is neither suitable
nor intended for mediating .so files the way we would need.)

- We also have some packages that don't like openssl-1.1 at all (most of
them are outdated) and need additional work.
- We also have some more packages with all kinds of different problems,
like linking against openssl version 1.1 and 1.0.0 simultaneously.

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).
Thus, we cannot (should not) update at different times because that will
likely create problems.

Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20210222/b027adf7/attachment.html>


More information about the oi-dev mailing list