[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: supertuxkart 0.7.3



On Mon, Dec 10, 2012 at 2:25 AM, Paul Wise <pabs@debian.org> wrote:
> On Mon, Dec 10, 2012 at 6:08 PM, Vincent Cheng wrote:
>
>> Well, I'm not thrilled at the prospect of using an embedded copy of
>> irrlicht in stk either. However, Policy 4.13 doesn't explicitly forbid
>> doing so (should != must), and hence why the security team has a list
>> of embedded code copies [1]. Upstream has indicated that at some point
>> in the future, their modifications to their embedded copy of irrlicht
>> is going to be extensive enough to break the API. If you've got any
>> other options I haven't considered yet, I'm all ears. :)
>
> Some options I can think of:
>
> Beg upstream to be reasonable and push their patches upstream.

This is what auria (one of stk's devs) said (in one of the bug reports
I linked earlier, i.e. [1]): "irrlicht is configured through a header,
and the irrlicht developers specifically told us to configure irrlicht
in our builds because they wouldn't change the defaults for everyone.
The logical conclusion is that since STK doesn't use the default
irrlicht configuration it must use its own irrlicht. So at this point
Linux distributions will need to accept to use a different irrlicht
for STK, otherwise they're just going to break STK. basically,
consider we are using a fork of irrlicht."

i.e. no.

(I don't know enough about irrlicht to say whether stk's devs could be
doing things differently, to be honest.)

> Add the supertuxkart patches to the Debian version of irrlicht,
> building two sets of packages from one source package, one with the
> patches, one without.

How would this be any less work than simply using the embedded copy of
irrlicht in stk's source? Building a set of binary packages just for
stk's use (libirrlicht-for-stk-{,dev,dbg,doc}) sounds just as painful
as statically linking irrlicht in stk.

> Patch supertuxkart to work with the upstream version of irrlicht.

Tried that, got bitten by a bunch of seemingly random and hard to
reproduce segfaults as a result (#677609; LP: #1011180, LP: #1048284,
LP: #1049398, LP: #1061436, LP: #1064019, LP: #1069871). The problem
is that upstream is releasing stable releases of stk that build-depend
on unreleased versions of irrlicht (e.g. stk 0.7.3 requires irrlicht
svn r3843).

> Remove supertuxkart from Debian if upstream refuses and the above
> patching gets to be too much effort.

Between this, or choosing to use embedded code copies, I'd rather go
with the latter.

Regards,
Vincent


Reply to: