Re: supertuxkart 0.7.3
On Mon, Dec 10, 2012 at 2:46 AM, Markus Koschany <apo@gambaru.de> wrote:
> On 10.12.2012 11:08, 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. :)
>
> Reading through the two bug reports you have mentioned, the following
> options are on the table IMO.
>
> 1. Releasing version X of STK with version Y of irrlicht and applying
> changes which were made upstream to STK via a patch. I think
> this is mainly a documentation issue and upstream should take care
> of it.
If what you mean is to patch Debian's irrlicht sources with the
modifications made by stk's devs...that's not a sustainable solution,
especially since upstream has stated that they may break irrlicht's
API with their modifications.
> 2. Replace irrlicht in Debian with the STK version. Seems to be no
> problem at the moment because only a few packages depend on it but
> would become an issue in the future if we include more games which
> depend on the official irrlicht version.
We already have at least one package in the archive that I know of
which depends on irrlicht other than stk (i.e. minetest). I'm not
about to break other unrelated packages because stk's devs decided
that they want to fork irrlicht.
> 3. Use the embedded copy of irrlicht and report the issue to the
> security team and track everything security related to STK and
> irrlicht carefully.
...which leaves us with option 3. :)
(Christoph, I'm not sure if you're following this thread, but I assume
you're subscribed to the list...anything else you may want to add to
the discussion?)
Regards,
Vincent
Reply to: