On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote: > My current plan is to not ship such engine-pkcs11 package. We should > try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a > compat package for third party binaries without -devel and any extra > bells and whistles. It would be also temporarily used in Rawhide so it > is installable but for that I think we can live with temporarily > breaking PKCS#11 uri support. If we move everything to 1.1 and nothing that *currently* supports PKCS#11 ends up broken in F26 because it's left behind on 1.0.2, then that works. Although building the engine alone for 1.0.2, without shipping a matching version of libp11 alongside it, would also be feasible. As for shipping without -devel... do we have a flag day in rawhide and just switch, either fixing the resulting FTBFS issues afterwards, or having had the fixes waiting in the wings to push to all the affected packages? I was imagining that we'd deploy the new OpenSSL 1.1 package but still allow other packages to build against 1.0.2 if they need to, at least for a little while — even if we plan to kill the 1.0.2 -devel package before we actually ship F26? 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. 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? -- dwmw2
<<attachment: smime.p7s>>
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
