On Fri, 2016-07-22 at 16:48 +0200, Tomas Mraz wrote:
On Pá, 2016-07-22 at 10:24 -0400, Simo Sorce wrote:
> On Fri, 2016-07-22 at 10:21 -0400, Simo Sorce wrote:
> >
> > On Fri, 2016-07-22 at 17:17 +0300, Antti Järvinen wrote:
> > >
> > > Tomas Mraz writes:
> > > > for anybody insterested in testing and/or porting applications
> > > to the
> > > > new OpenSSL 1.1.0 API I've prepared a COPR repository:
> > >
> > > Strongly advised, OpenSSL 1.1 API changes slightly compared to
> > > 1.0 and
> > > at least in debian the list of packages not compiling any more
> > > was rather
> > > impressive, see
> > >
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061
> > > and I'd expect something similar in other distributions too.
> > > Mostly
> > > this is head-ache of upstreams but it might be good manners to
> > > file
> > > upstream error tickets early :)
> > Second, I was given a heads up about failing packages by an Ubuntu
> > maintainer of upstream projects of mine, and I had to change every
> > single one of them. I haven't rebuild all of them yet for Fedora
> > either
> > because the changes do not work at run time, I have to wait until
> > Feodra
> > Rawhide gets 1.1.0 anyway.
> >
> > So please land this as early as possible in Fedora as it will
> > require to
> Actually , given how disruptive this is going to be we may want to
> think
> of creating a separate tag and rebuild the majority of core packages
> that break there and only then tag it at once in rawhide, or rawhide
> user experience will be miserable until all package maintainers get
> around to fix it.
My current plan (might be changed) is to:
1. Fill Fedora Change proposal for Fedora 26 very early.
2. Add compat 1.0.2 package which would be used by 3rd party
applications and also temporarily by applications that are not yet
ported to the new API. However the current plan is to not provide
-devel subpackage for 1.0.2 compat packages so if you needed to rebuild
something on rawhide you would have to fix the build issues with the
new openssl.
The tag should not be strictly necessary and I'd like to avoid it as
rawhide with the compat package should be installable and relatively
usable. Only the developers that use OpenSSL API calls would have to
patch their code.
I am concerned about a compat package because there are a lot of
components lining to openssl often libraries or modules, from different
source RPMS. So we incur the risk of getting a binary to link with both
version via modules/library dependencies and that would cause issues
(probably crashes, or perhaps bad behavior) only at runtime due to
symbol aliasing between the two versions.
Simo.
--
Simo Sorce * Red Hat, Inc * New York