[oi-dev] openssl and gmake REQUIRED_PACKAGES

[stes@PANDORA.BE]

Hi,

----- Op 22 feb 2021 om 22:29 schreef Andreas Wacknitz A.Wacknitz at gmx.de:

> - 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.

Incrementing the COMPONENT_REVISION is indeed essential,
if the version of the package remains the same.

So it must be checked that that works for all components
(incrementing the COMPONENT_REVISION and rebuild)

I wasn't aware of USE_OPENSSL_11=yes

so I'll give that a try.

In any case, I'm OK with whatever approach is used or choosen,
I was just inquiring about what the plan or strategy is,
and whether I have to do something for it in the Squeak component.

My impression is that the most important thing (this may be obvious),
is that if possible OpenSSL dependencies are avoided at all.

This is for Smalltalk-80 the case.

Back in 1972 or 1980 there obviously was no OpenSSL,
and the kernel of Smalltalk (Squeak) has no dependency on OpenSSL.

In fact I could compile Squeqk without OpenSSL at all.

What I do now is separate the packages:

   - squeak main package  has the OpenSSL plugin
   - squeak-nodisplay for squeak core or kernel has no OpenSSL plugin

Obviously by limitting the number of packages that require OpenSSL,
that is the best way to avoid the large list of packages that require OpenSSL.

If Smalltalk / Squeak is packaged as one big blob,
then there is a dependency.

IPS is just doing its work by pointing out that in that case Squeak depends on OpenSSL.

However IPS is also able to see that if I separate kernel and plugins,
then that's it the plugins that depend on OpenSSL and not the kernel.

So whatever approach is used, I'm fine with it.

IPS is just doing it's (intented) work of pointing out and alerting about the dependencies.

Regards,
David Stes