SDL2 2.0.4 is out!

[Gianfranco Costamagna]

Hi Manuel,


>There's abigail-tools and https://github.com/lvc/abi-tracker
>(successor to the sadly abandoned effort of "upstream tracker" website
>which used to have SDL libs.
>
>I never used them though.

I know there are some tools, but I think we already have an answer :)

(and I try to avoid them whenever possible, because AFAIK none of them 

is really reliable)

>Yup.  But maybe no package in Debian uses that, so until we try to
>rebuild we will not know.


well, no package in Debian might use that, but there are an hundred of changed
structs, or even more, and checking them is unfeasible

BTW no package in Debian might use that, but this doesn't mean we can 

upload without bumping ABI/API.

e.g. we might introduce troubles to Debian derivatives (they might have more packages
than us), but more important we might introduce troubles to folks
with custom compiled software on their computer.

I honestly think about people playing games not in the archive, who will see their favourite
game segfault without no apparent reason.

Is that what we want?


>I am not sure if it's ABI safe even in this case, depending on the
>things that people can do when using it.  For example, if one creates
>an array of such structs and accesses elements of it by their size
>indirectly (like incrementing the size of the pointer), it will be
>problematic.


I fully agree, but we can't check 125k LOC and for each suspicious change all the ~50
reverse-deps for the actual use case
(and we might even still have troubles because of software in the archive)

>One way to know would be to ask them, maybe they confirm it in one way

>or another.

actually they broke ABI with sdlgfx2 IIRC, so they might not give an appropriate answer :)

(BTW, changing names to structs and adding fields to them, is clearly ABI incompatible,
so we can't rely on the fact that they have been added at the end, and probably nobody
will do a sizeof and rely on the output)


>In general I think that it would be better to schedule a rebuild, just
>in case.  It doesn't hurt to rebuild the packages every few months or
>years.  But release team is general against such rebuilds.


well, I fully agree, bumping and rebuilding is safe, and unless proven that 125k of patch
changes are completely safe, there is nothing that will avoid that.

(better safe then sorry, specially when we have more examples of breakage in the patch!)


>I guess that the steps can be:
>
>1) Upload to experimental
>


ok seems legit


>2) Rebuild rdeps, see if any of them break (candidates can be easily
>found with the "search source" service, searching for elements that
>changed like SDL_AssertState).  At some point, all rdeps should be
>rebuilt to see what breaks.
>

yes, this way we will even have a better look about how many structs
have been renamed :)

>3) Submit patches etc, or at least requests for maintainers to help
>porting their own stuff.


sure


>4) Check what to do with release team.  If it's OK for them, agree if
>binNMU of those which are API-compatible is OK.


yes, we will need to upload to unstable (after all the reverse dependencies
are fixed), and then schedule the NMU/binNMU
(this point actually really depends on the kind of breakage we will see I think)


>...) ?


5) see the new sdl migrate to testing :)


I still need to understand how to bump the ABI/API and then I'll perform the unstable upload.

if you can give me an hint I'll be happy to follow up with the transition!

cheers,

Gianfranco