On Sun, Feb 25, 2024 at 02:32:14AM +0100, Goetz T. Fischer wrote:
> On Sat, 24 Feb 2024 19:23:33 +0100, Marcel Telka wrote:
> > Hi,
> >
> > On Sat, Feb 24, 2024 at 06:27:30PM +0100, Goetz T. Fischer wrote:
> >> as you know there're still some packages in the repo that use openssl
> >> 1.0.2.
> >> so
> >> far this had the unpleasant implication that all new packages had to be
> >> hardcoded to newer ssl versions one way or the other, because the
> >> buildsystem's
> >> ssl mediator had to remain at 1.0.
> >
> > Sorry, this is not true.
>
> see ##1 below ...
Sorry. I proved that you need to do exactly _nothing_ to get OpenSSL
3.1 for a component and your argument is ...
that's the (potentially unnecessary) work i refered to.
Huh?
>
> > It is already the other way around because the default OpenSSL version
> > in the build framework is 3.1:
> >
> > $ grep OPENSSL_DEFAULT make-rules/shared-macros.mk
> > OPENSSL_DEFAULT = 3.1
> > OPENSSL_VERSION ?= $(OPENSSL_DEFAULT)
> > $
> >
> > So in other words when a component needs non-default OpenSSL then it
> > needs to specify the desired version via the OPENSSL_VERSION macro in
> > its Makefile.
>
> which can be omitted if the desired version is the default 3.1 according to
> https://github.com/OpenIndiana/oi-userland/pull/16202#discussion_r1496941478
Sorry, I do not understand what is your argument here. I said: OpenSSL
3.1 is default and you need to do nothing to get it. If you need
non-default, you need to specify one.
So what exactly can be ommitted? Specification of non-default? Really?
At the URL you are referring to is stated the same: OpenSSL 3.1 is
default.
>
> > And, in an ideal world this should be all that is needed re the OpenSSL
> > support and versions for a component (see cryptography above for an
> > example).
>
> as we all know, the ideal case is not the case all the time. hence ...
I agree. Some software does not do proper detection of OpenSSL so we
need to help them.
>
> >> i.e. only hardcoding the handful of packages which, for whatever reason,
> >> still
> >> need 1.0.2 and having the buildsystem's ssl mediator set to whatever is
> >
> > The openssl mediator (on build machine) is orthogonal to that. All
> > components builds should produce same results with any openssl mediator
> > setting.
>
> ... exactly that's what i wanted to "optimize out" so to speak.
Sorry, no way. That would not be an optimization, but step back. We
worked hard in past to be mediator agnostic as much as possible and this
is the right way to go.
Actually, I like to see the default openssl mediator to be set to so
ancient OpenSSL version because it clearly shows all components that do
not have proper OpenSSL integration.
> my recent tries with userland showed that the mentioned shared macros are not
> enough to make the buildsystems of various programs recognize an ssl version,
> other than what the mediator is set to, as default. therefore having the
> mediator set to whatever is considered the default at the time would be the
> most efficient option, because it requires the least extra work for each
> package.
As I already said that's the problem with such programs and should be
addresses there. See also below for a case study.
>
> > Provided the OpenSSL support in a packaged component is done
> > properly.
>
> ##1 that's the (potentially unnecessary) work i refered to.
>
> > A package needing old(er) OpenSSL is not a problem
>
> oh that depends on the package. having nginx still use 1.0.2 for example is
> not
> good for more than just one reason.
This opens an interresting question: How should a software detect
OpenSSL and everything related (paths to include files, libraries,
compliler flags, etc.)? We are not first humans who asked this question
and ... voila ... some wise people developed pkg-config more than 20
years ago to solve this problem.
Any random software have basically two ways how to get required
information regarding other libraries they wish to use: either to use
pkg-config (or something similar) or try to do the hard work on their
own.
Failures of the pkg-config way are extremely rare (guess why), but the
"on their own" way failiures are common (guess why). And the only way
how to make such failing software to build properly is to do some more
manual work.
What way uses nginx to build with OpenSSL? You can guess. Why they do
so? I do not know. You can try to ask them. Maybe they didn't notice
pkg-config yet, maybe they hate it for some reason, or maybe they just
need somebody to do the work to use pkg-config.
In any case, yes, we need to do some more work to make nginx to build
properly with OpenSSL. Maybe it is enough to just uncomment the
--with-openssl line in the Makefile.
>
> > Somebody just needs to
> > sit down and do the work (and then create a PR). Things do not
> > materialize from nowhere.
>
> i never said they would.
> in fact the reason why i brought this up is to end up with a pr
