Bug#788061: Bug#788057: game-data-packager: please add support for Blake Stone: Aliens of Gold and Planet Strike

[Braden Obrzut]

On 30/06/15 14:40, Manuel A. Fernandez Montecelo wrote:
> I have had a look at some of the patches, not in much detail though
> (I'm in a bit of a rush in the last few weeks).
>
> Perhaps some of them, at least the most simple and obvious, should be
> (if not done already) reported in the bug tracker, attaching the
> particular patch fixing the issue.  I saw upstream happily accepting
> patches in the past (although they are a bit slow to react sometimes).
>
> So Braden already did the right think in trying to upstream his
> changes, but breaking them down to small pieces for individual
> consideration will help a lot in the process, I think.
That's why I posted on the mailing list.  If there's anything in there 
that would be accepted, I can break it out.  But it just wastes my time 
to break out patches for everything and have them be denied.  The fact 
of the matter is ECWolf needs all the features added or the sound engine 
is going to be gimped.  (Which means some of the commercial games won't 
work 100% and some moding features will be disabled.)

I suppose what frustrates me a little about the situation is that if I 
merged that source code into the ECWolf tree and didn't mention it, it 
would be packaged without a second thought, but since it's a separate 
repo in order to allow me to trivially merge any changes from upstream 
it's a big deal.  To be clear, I'd never suggest that Debian provide the 
library in a separate package.  Only statically linking. ;)  But I'm 
glad that you guys are even considering packaging it at all.
> In principle, I think that the changes as a whole are too big and
> intrusive to try to add them to Debian.  I am sure that some/most are
> good fixes, but we have had continous problems with adding some patch
> that people request to fix a problem in their project, and then
> breaking another application for not obvious reasons, sometimes those
> other applications even rely on the wrong/old behaviour.  So adding
> patches without support from upstream is a bit of a mine-field.
I would agree.  I think at least one of the changes in its current 
implementation breaks ABI, I think it's one that fixes a mismatched free 
too.
> Maybe it's obvious from previous context, but I didn't see how this
> applied to SDL-1.2 and not v2?  I think that specially the mixer
> module is quite independent from other changes of the v2 library, so I
> think that many might apply to v2 as well.
My customized SDL_mixer is based of SDL_mixer 2.0.  SDL_mixer 2.0 can 
actually be compiled against SDL 1.2 or 2.0 just fine, so I imagine the 
branch is just there for ABI reasons.
> Speaking of which, if an active software has not considered starting
> to use v2 already, at least they should make a plan.  We don't plan to
> retire 1.2 immediately, but it's obvious that upstream does not do any
> releases of that branch, nor probably even accepts patches, so it
> starts to be urgent to move on to the supported versions.
>
ECWolf compiles with SDL 2.0 starting with the recently released 1.3.2.  
I hear it doesn't compile with stock SDL_mixer 2.0 due to the way I call 
a certain function, but I haven't bothered checking it yet.

I'll answer the unaddressed points of the previous email (the one asking 
for the Blake Stone MD5s etc) later.

- Braden "Blzut3" Obrzut