The road to SDL2 2.0.7

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Fri Nov 3 23:30:21 UTC 2017


(I guess that you're subscribed, but just in case)


2017-11-03 7:32 GMT+01:00 Fabian Greffrath <fabian at debian.org>:
> Dear team mates,
>
> I have started the work on packaging SDL2 2.0.7 just yesterday and -
> although everything seemed to go as expected - a few questions arose:
>
>  - We don't ship a symbols file but increase SHLIBVER manually in
> debian/rules. Is there a specific reason for that?

The reason is partly historical, probably partly personal, possibly
partly because it didn't work very well.

Historical in the sense that it was not implemented by the time that
the people currently active took over (~2012 IIRC), personal in the
sense that I don't have a fondness or full understanding of symbols,
and the part that it didn't work very well is that some modules
exposed too many or wrong symbols like internal functions, IIRC -- but
don't ask me for more details, I don't remember.

Part of the reason is also that SDL was kind of very stagnant from the
early '00s until ~2012, when they went ahead with SDL v2, so there was
not much need for changes for a decade.

To explain a bit more about the personal reasons, one is that many of
my other packages are C++, and the situation there is a bit messy from
what I could understood (posts from Russ in Debian planet a few years
ago).

Also, because when porting to new architectures (in which I was
working in the last few years), part of the most repetitive/annoying
task is to upload new versions of packages symbols, otherwise they
don't compile cleanly, and this is much more time consuming in my
experience than porting memory allocators or other packages that need
actual changes to the upstream part.

So from a personal view, I always felt --perhaps wrongly, or
biasedly-- that it was more of a pain than a gain for the project.

Finally, they are really commited to ABI stability in the last few
years, so they treat problematic ABI changes very seriously.


All that said, I am not really opposed to change this aspect.  I would
like to understand it properly though, specially the amount of extra
work that it will/might take for new releases.


>  - We don't build with any hardening flags. Again, is there any
> specific reason for that?

In what way?  AFAICT from rules, it doesn't build with /extra/ flags,
but it should get the default ones.

(Apart from that, being mostly used for games and
performance-senstiive applications, I think that we never tried to
harden the build when the price to pay was high-ish, which I think
that happened at least initially).


>  - Since version 2.0.6 SDL2 features audio resampling with
> libsamplerate, but our package doesn't support that yet. Is this an
> oversight, or have we decided against this in the past?

Oversight :)


> There may be other questions, but these are the most pressing ones for
> now.

Yep, keep them coming.  Perhaps I'll not be the most responsive, but
I'll try to reply to any question that you might have.

And thanks for working on this!


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>



More information about the Pkg-sdl-maintainers mailing list