Re: supertuxkart 0.7.3
On Mon, Dec 10, 2012 at 3:29 AM, Markus Koschany <apo@gambaru.de> wrote:
> On 10.12.2012 12:01, Vincent Cheng wrote:
>> On Mon, Dec 10, 2012 at 2:46 AM, Markus Koschany <apo@gambaru.de> wrote:
>>> 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.
>
> Actually i meant the same thing Paul mentioned before. Why is it easier
> to track changes to an embedded code copy of irrlicht in STK than to
> build two packages from the same source of irrlicht, one with the STK
> patch and the other one without?
(Also in response to pabs/tobias:)
IMHO it would be less work to just use the embedded copy of irrlicht
in supertuxkart, compared to patching cmake config files to get stk to
build with Debian's irrlicht, and then running a diff and merging the
changes into Debian's irrlicht. It also means that everytime I upload
a new upstream release of supertuxkart, I would also have to make an
irrlicht upload as well. It's not really that much more work, but I
don't see what I'd gain through this approach, rather than just using
stk's embedded copy of irrlicht. If a security issue is found in
irrlicht, patching it would involve the same amount of work with
either approach. (And on the topic of security, I'd consider irrlicht
to be a fairly low-risk library; only a single CVE (CVE-2008-5876) has
ever been issued for it.)
Vincent
Reply to: