2016-12-22 16:39 GMT+01:00 Dirk Eddelbuettel <e...@debian.org>: > > Can we agree to delete material that has been quoted several times already? > > On 22 December 2016 at 14:56, Bálint Réczey wrote: > | > I think we're closing to deadlock situation. I think we all would like to > | > move to 2.1 everywhere. You say you can, so you want to do more > deprecated > | > functions ... but that just worsens the situation. > | > | I'm not sure what you mean by "do more deprecated functions". > | I have to to keep rb-gsl's external API and my proposal was providing > | the deprecated > | functions in gls thus rb-gsl can wrap them and keep providing the Ruby > | interface. > > Let me restart: > > 1) GSL is at version 2.2. It is in Debian. > > 2) It has optional support for old stuff. We all agree that old stuff > is not desirable. We try to avoid it. > > 3) You bug was filed for version 1.6something of rb-gsl. > > 4) I noticed that rb-gsl appears to be at 2.1 as well. > > 5) Should GSL and rb-gsl not both be current?
They both should be current. > > | If that means removing functions from the API provided by rb-gsl then > | this is a no-go for me because that would make Debian's rb-gsl 2.1 > | having a different API form rb-gsl 2.1 available elsewhere and there > | is no practical way of distinguishing those in Ruby - unlike using > | different .so names in libraries with C interface. > > For the very same reason I am reluctant to enable deprecated functions. > We can and have, but I would prefer not to. > > But as I recall it is just an add-on and should not be harmful. > > | If your proposal is keeping deprecated functions disabled in GLS and > > So you mean GSL when you say GLS ? Yes, forgive my typos. > > | reimplementing them in rb-gsl and wrapping those functions int > | rb-gsl-s unchanged API then that would work in theory and this is what > | I started doing in the attached patch. However this approach needs > | more work which I can't promise to do, and more importantly does not > | seem to be better option for GSL/rb-gsl users, just for GSL upstream. > | > | As a user of an API I always prefer having deprecated functions > | available, except when I work on migrating away for the deprecated > | functions and disabling the completely help discovering the parts to > | fix. > > I agree in the abstract sense (and as a user). > > As a packager (for 20+ years) I have come to realize that upstream generally > knows better than me. > > So getting very concrete: You are asking for a rebuild of gsl_2.2.1 with > this turned off / removed: > > AH_VERBATIM([GSL_DISABLE_DEPRECATED], > [/* Disable deprecated functions and enums while building */ > #define GSL_DISABLE_DEPRECATED 1]) Yes, please. Cheers, Balint > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
