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

Re: supertuxkart 0.7.3



On Mon, Dec 10, 2012 at 1:31 AM, Bas Wijnen <wijnen@debian.org> wrote:
> On 10-12-12 01:02, Vincent Cheng wrote:
>> On Sun, Dec 9, 2012 at 3:24 PM, Tobias Hansen <thansen@debian.org> wrote:
>>> Am 10.12.2012 00:04, schrieb Vincent Cheng:
>>>> On Sun, Dec 9, 2012 at 8:15 AM, Tobias Hansen <thansen@debian.org> wrote:
>>>>> If it's a bug in irrlicht, you can find the patch in the irrlicht svn. If
>>>>
>>>> Uhmm, thanks? Especially after tagging #677609 and #679837 with
>>>> 'help', I was hoping for something a bit more detailed/specific...
>>>>
>>>> [2] https://sourceforge.net/apps/trac/supertuxkart/ticket/689
>>>
>>> I have not looked into it. My point was that modifying a library to
>>> match the needs of one of its reverse dependencies is a bad idea. After
>>> looking at your [2], it looks like that is what this is about.
>>
>> No, I haven't modified irrlicht to meet the needs of supertuxkart.
>> It's an option that I have considered though; either that, or just use
>> supertuxkart's embedded copy of irrlicht starting with the next
>> upstream release. I'm leaning towards the latter because it's the
>> least painful option.
>
> I hope this is not true, because it is a very painful option. This is
> the reason it is also forbidden by Policy (4.13). Footnote 30 is quite
> clear:
>
>> Having multiple copies of the same code in Debian is inefficient,
>> often creates either static linking or shared library conflicts, and,
>> most importantly, increases the difficulty of handling security
>> vulnerabilities in the duplicated code.
>

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. :)

Regards,
Vincent

[1] http://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup


Reply to: