SDL 2.0 RC1 and DirectFB

Felix Geyer fgeyer at
Sat Jun 1 15:31:26 UTC 2013

On 01.06.2013 16:34, Manuel A. Fernandez Montecelo wrote:
> 2013/6/1 Felix Geyer <fgeyer at>:
>> Hi,
>> I've started packaging SDL 2.0.0 RC1 and noticed that the
>> DirectFB support is in bad shape.
>> It has obvious syntax errors and you get a bunch of other compiler
>> errors when you try to build it.
>> Upstream has also disabled it by default (was enabled in 1.2).
>> Do we want/need to support DirectFB?
> If it's not enabled by default and with errors, I'd say to disable it.
>  We can revert if somebody actually asks for it and it's fixed at a
> later point.

Agreed, let's just see if somebody complains. :)

>> There is also a release candidate for SDL_image available
> Is it?  I didn't see it in the website for the module, nor main
> website, nor tagged as such in the repositories.  In
> fact, I've been monitoring it since quite a while ago from time to
> time and I haven't seen a definitive -RC to serve as trigger to
> package it.

There is an announcement on the SDL mailing list with a link to

>> so we need to settle for a package naming scheme.
>> [...]
>> Personally I'd prefer using the upstream tarball name but don't have
>> a strong opinion about that.
> I also don't have a strong opinion of that, but let's try to make this
> discussion the definitive one because it's a recurring topic :-)  (not
> blaming you for bringing it up, on the contrary, thanks for bringing
> it up on the mailing list).
>> I guess the options are sdl2-image (matches upstream tarball),
>> sdl-image2 (matches 1.2 naming scheme), libsdl2-image (matches libsdl2
>> name) or libsdl-image2.
> I think that it makes sense to use the same name as upstream (although
> we cannot maintain it completely, for example we cannot use the
> underscore nor uppercase, I think); and for me it also makes sense to
> follow the idea of having "lib" as prefix.
> For me, maintaining the trend of [lib]sdl-moduleVERSION doesn't make
> sense, because neither upstream is named like that, nor it will
> probably be named like that in other distributions.  Maintaining the
> trend with our previous package names is not worth pursuing in my
> opinion, given that it doesn't cause problems or unnecessary overhead
> -- so this is the ideal time to break it.
> So I would prefer either sdl2-module or libsdl2-module (slightly more
> this one because the other is not exactly the same as upstream
> anyway).  I don't think that we should do [lib]sdl-moduleVERSION.
> Now, apart from the above, I would also like to maintain some
> coherence with all v2 packages, and there's already src:libsdl2, so if
> we choose "sdl2-module" I would like to change the main library to
> "sdl2".

Ok, let's use libsdl2-MODULE before we start renaming packages
again. :)

> And now that we are at it, I thikn that all binary packages should be
> named libsdl2 (with -dev/-doc/-dbg/-etc), libsdl2-module (also
> libsdl-module-dev/-doc/-dbg/-etc).

The Debian policy says library (binary) packages should be named
librarynameSOVERSION or libraryname-SOVERSION.
For example the package for should have been called

I'd expect for SDL2_image it would be libsdl2-image0.
The dev and debug packages could then be called libsdl2-image-dev and


More information about the Pkg-sdl-maintainers mailing list