Hi folks,
I am the debian maintainer of sdl_image, sdl_mixer and a few sdl based
games. Since SDL 1.1.5 is out quite some bug reports are coming in,
sdl_image and games are not longer working correctly. Something in the alpha
channel (sdl_image) has changed, so images don’t show correctly anymore.
One proposal was to build all games and sdl_image, sdl_mixer with stable sdl
libraries, however sdl_image and _mixer seem to require SDL1.1.x since a
few revisions. Which one is the latest which still builds with SDL1.0?
Is there a chance to get two source trees for sdl_image+mixer, like with
SDL? Even numbers (1.0) for libraries which build with stable SDL, uneven
numbers (1.1) for libraries which build with unstable SDL?
This might solve all my problems in one go.
Christian
PS Please Cc me on replies, I am only subscribed to sdl-announce.
I am the debian maintainer of sdl_image, sdl_mixer and a few sdl based
games. Since SDL 1.1.5 is out quite some bug reports are coming in,
sdl_image and games are not longer working correctly. Something in the alpha
channel (sdl_image) has changed, so images don’t show correctly anymore.
SDL_image 1.0.10 requires SDL 1.1.5 or later. Earlier releases of SDL_image
will not load alpha channels correctly with SDL 1.1.5 or later.
Thus SDL 1.0.x should use SDL_image 1.0.9
Is there a chance to get two source trees for sdl_image+mixer, like with
SDL? Even numbers (1.0) for libraries which build with stable SDL, uneven
numbers (1.1) for libraries which build with unstable SDL?
I don’t mind, but it feels like an overkill since those libs don’t change
much
I am the debian maintainer of sdl_image, sdl_mixer and a few sdl based
games. Since SDL 1.1.5 is out quite some bug reports are coming in,
sdl_image and games are not longer working correctly. Something in the alpha
channel (sdl_image) has changed, so images don’t show correctly anymore.
SDL_image 1.0.10 requires SDL 1.1.5 or later. Earlier releases of SDL_image
will not load alpha channels correctly with SDL 1.1.5 or later.
Thus SDL 1.0.x should use SDL_image 1.0.9
1.0.8, 1.0.9 needs SDL 1.1.3 AFAIK
Is there a chance to get two source trees for sdl_image+mixer, like with
SDL? Even numbers (1.0) for libraries which build with stable SDL, uneven
numbers (1.1) for libraries which build with unstable SDL?
I don’t mind, but it feels like an overkill since those libs don’t change
much
They don’t change much, but they did between 1.0.8 and 1.0.9 wrt the
stable/unstable SDL versions. IMHO this is bad. I think these three bugs are
caused by this (there might be more in other SDL based packages): http://bugs.debian.org/72819 http://bugs.debian.org/72860 http://bugs.debian.org/72975
I think I have to create a new stable package 1.0.8 to fix this, I would
rather like to create a new unstable package 1.1.x and leave the stable
package as it is. Is this possible? Ie 1.0.11 == 1.0.8 and 1.1.1 == 1.0.10
or something.
ChristianOn Wed, Oct 04, 2000 at 02:24:10PM +0200, Mattias Engdeg?rd wrote:
Could be; probably nobody made an effort to keep the compatibility
backwards.
Actually, the separation of SDL and its auxiliary but nevertheless
"standard" libs (SDL_mixer, SDL_image, SDL_ttf, etc) is more an
implementation detail than a logical separation. Nothing forces a
one-to-one mapping onto packages. In fact, if I maintained a package, I
would bundle at least SDL_image and SDL_mixer in the same package as SDL.
It would solve all your problems, and make life easier for the users as
well - they will almost always need the auxiliary libs and the latter
tend to be fairly small
Could be; probably nobody made an effort to keep the compatibility
backwards.
Uh, thats bad IMHO…
Actually, the separation of SDL and its auxiliary but nevertheless
"standard" libs (SDL_mixer, SDL_image, SDL_ttf, etc) is more an
implementation detail than a logical separation. Nothing forces a
one-to-one mapping onto packages. In fact, if I maintained a package, I
would bundle at least SDL_image and SDL_mixer in the same package as SDL.
It would solve all your problems, and make life easier for the users as
well - they will almost always need the auxiliary libs and the latter
tend to be fairly small
Well. I am not the debian SDL maintainer, I only maintain two of the
auxiliary packages, since the SDL maintainer did not want the other
packages. SDL_ttf is maintained by somebody else, I did not want it, because
of the unclear license. Debian works nicely with seperated packages and its
dependencies, however seperating stable and unstable versions is a benefit
for the user, thats why I’d prefer the clear seperation in the auxiliary
libraries as well, just like its done on SDL, in the kernel, in gimp, …
Disussing the benefits of one large or many small debian packages probably
belongs to some debian list, I just want one answer: Will you create a stable
and an unstable branch of the auxiliary libraries or do I have to create a
workaround for debian?
ChristianOn Wed, Oct 04, 2000 at 03:13:27PM +0200, Mattias Engdeg?rd wrote:
This is up to Sam. I won’t spend any time maintaining old branches myself
Mattias, I told you this would bite us.
I’ll put backwards compatibility into the next version of SDL_image, so
it compiles and works properly with SDL 1.1.4 and earlier. The alpha
invert flag (IMG_InvertAlpha) will be removed, but the alpha will load
correctly.
However, I highly recommend that the SDL 1.1 package be upgraded to the
upcoming SDL 1.1.6, as the alpha support is MUCH better in this release
than any previous release. I will still keep the backwards compatibility
for the SDL 1.0 series.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’ll put backwards compatibility into the next version of SDL_image, so
it compiles and works properly with SDL 1.1.4 and earlier. The alpha
invert flag (IMG_InvertAlpha) will be removed, but the alpha will load
correctly.
I thought about doing this for SDL_image but decided that adding cruft for
something that would not be needed anyway was just unnecessary.
Any reason why SDL_image 1.0. can’t be used with SDL 1.0.x?
That way we won’t have to keep that ugly flipping code there any more
I’ll put backwards compatibility into the next version of SDL_image, so
it compiles and works properly with SDL 1.1.4 and earlier. The alpha
invert flag (IMG_InvertAlpha) will be removed, but the alpha will load
correctly.
I thought about doing this for SDL_image but decided that adding cruft for
something that would not be needed anyway was just unnecessary.
Any reason why SDL_image 1.0. can’t be used with SDL 1.0.x?
That way we won’t have to keep that ugly flipping code there any more
I am fine with that, I am only asking you to change the version number of
sdl-image to 1.1, if it requires sdl1.1. That way all libraries can coexist.
What I would like to see is:
stable: sdl1.0 and sdl-image1.0 (1.0.8)
unstable: sdl1.1 and sdl-image1.1 (which is now 1.0.10)
Thats not really hard and I do not ask for improvements of the code, no
backwards compatibility, I just would like to see a version number change.
Is that possible?
I am fine with that, I am only asking you to change the version number of
sdl-image to 1.1, if it requires sdl1.1. That way all libraries can coexist.
What I would like to see is:
stable: sdl1.0 and sdl-image1.0 (1.0.8)
unstable: sdl1.1 and sdl-image1.1 (which is now 1.0.10)
Thats not really hard and I do not ask for improvements of the code, no
backwards compatibility, I just would like to see a version number change.
Is that possible?
stable: sdl1.0 and sdl-image1.0 (1.0.8)
unstable: sdl1.1 and sdl-image1.1 (which is now 1.0.10)
This seems like a good idea to me too. This reminds me of when
tcl and tk had separate version numbers, because they were nominally
decoupled; but it was ferociously difficult to know which tcl 7.x
could go with which tk 4.x. For tcl/tk 8, they aligned the version
numbers, and the problem went away.
Fine with Sam it seems. Sorry for being such a nerve, but when will you do
it? And what will you do? I am most interested to know, if you will make a
new, final sdl-image1.0 version, with a higher version number than currently
available and in the same move, create a 1.1 version, from the current
source (1.0.10), or if you will just create 1.1 whenever a new sdl-image
version is ready and leave 1.0 as it is?
I am asking because several packages in debian/unstable do not work anymore
as expected, and I’d like to fix sdl-image as soon as possible, with as
little problems for the future as necessary, ie I would prefer action plan
number 1, but of course this means more work for you. With plan number 2, I
would have to introduce an epoch into the debian package, which I would like
to do only if all else fails.
Thanks,
Christian
PS Please Cc me, I subscribed only to sdl-announce.On Tue, Oct 10, 2000 at 02:49:03PM +0200, Mattias Engdeg?rd wrote:
