On Mon, 2016-09-26 at 12:29 +0200, Tomas Mraz wrote:
My current plan is to just switch and rebuild fixing the FTBFS
during
that. I want to persuade some of my colleagues to help me with that
(and of course community help is also welcome).
Also we will be sharing the work with other downstream distributions
here:
https://github.com/patch-exchange/openssl-1.1-transition
Hm... might I suggest that every patch in there be tagged with an
'upstream status', and a link to the mailing list archive or ticket or
pull request where it was submitted upstream?
For which, the patches would actually need to be *acceptable* upstream.
At a quick glance, it looks like the wpa_supplicant one at least would
not be, because I think it'll break the build with OpenSSL <= 1.0.2.
> We'd probably want to *stop* using /usr/include/openssl in
that case;
> the pkg-config files can set the include path, so everyone should cope
> with that, and we don't want them accidentally picking up the *wrong*
> header files.
I currently did not want to do that as some dependent packages might
not use pkg-config and would have to be patched to use the different
include directory anyway.
Some might not but most would, and all SHOULD. If we did ship parallel
-devel packages, then I really think we'd need to move them. So then we
get a nice clean failure and not a horrid mismatch of headers which
might lead to more subtle bugs.
But if we don't want to ship parallel -devel packages, that's fine.
> But then again.... what happens when we end up with both
versions of
> OpenSSL loaded into a process? Even if we've converted everything in
> Fedora and it's only third-party stuff that still uses a compat-1.0.2
> package... if it loads other Fedora libraries which are using 1.1, we
> end up with both. Isn't that going to end in tears? Is it even viable
> to ship both at once? Or do we fix that with symbol versioning?
I've tested some scenarios - particularly running Apache with mod_ssl
and libkrb5 linked to 1.0.2 and mod_auth_gssapi linked to 1.1.0 worked
fine. So hopefully the symbol versioning works and allows this.
Great. I've seen occasional problems but I've been doing my own local
builds of random versions of OpenSSL, without the --default-symver that
our package adds.
--
dwmw2