On Po, 2016-09-26 at 09:35 +0100, David Woodhouse wrote: > 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? 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 > 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. 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. > 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. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
