Re: OpenSSL 1.1.0 in Rawhide very soon
Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> Tomas Mraz wrote:
>> At worst if the patching of a package is highly non-trivial and the
>> upstream is not responsive we might have to drop the package from
>> Fedora.
>>
>> We do not want to keep 1.0.2 devel around as that could make it to
>> look
>> like the 1.0.2 is still fully "supported" in Fedora and there would
>> be
>> no incentive to switch to 1.1.0. Also to get any new features from
>> upstream OpenSSL we have to move to newer versions as they are
>> released
>> as the old versions get only bug fixes.
> IMHO, this is not acceptable. If the API of a library changes enough
> to
> warrant a compat package, you have to provide the -devel for the
> compat
> package as well. Dropping all the packages that don't build against
> the new
> incompatible version from Fedora is not a reasonable plan.
We will work on porting the dependent packages to the new API. If by
some reasonable deadline there are still some packages that are not
dead by other reasons and we are unable to port them we can add -devel
to the compat package. Note though that small changes in such packages
will be needed anyway as the include files of the compat package will
have to be in non-default include directory. (If the package doesn't
use pkgconfig to find the needed CFLAGS automatically.)
But what about stable versions of libraries applications? For example,
in current Rawhide, you won't be able to build any stable Ruby version
downloaded as tarball without the compat-openssl-devel. And it is
question, if upstream will be able to backport the OpenSSL 1.1.0 support
into stable Ruby versions [1]. Not mentioning all the older Ruby
versions which are unsupported, but up until now, you could build them
on your own (actually it should be possible to disable the OpenSSL
support, but that is not common scenario).
I personally don't care much about this scenario, but I am pretty sure
that others might care more ....
Vít
[1] https://bugs.ruby-lang.org/issues/12830#note-2