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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
