Re: supertuxkart 0.7.3
On Tue, Dec 11, 2012 at 9:35 AM, Bas Wijnen <wijnen@debian.org> wrote:
> Some thoughts I sent earlier, but haven't reached the list for some reason:
>
> -------- Original Message --------
> Subject: Re: supertuxkart 0.7.3
> Date: Mon, 10 Dec 2012 13:17:58 +0100
> From: Bas Wijnen <wijnen@debian.org>
> To: debian-devel-games@lists.debian.org
>
> On Mon, Dec 10, 2012 at 12:29:14PM +0100, Markus Koschany 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?
>
> The other thing that was mentioned, but seems to be forgotten, is the
> option to fix this in irrlicht. AIUI the problem is that some
> application-specific configuration of the library is done through a
> header file, which means that every application using irrlicht will in
> principle need to compile its own copy. In that case there are two
> things to consider:
>
> - If it really is so bad, irrlicht should not be distributed as a
> library package, but only as source (not a debian source package, but
> a binary package containing the source) which is to be used as a
> build-dep for the packages using it. Each package using the library is
> then indeed compiling the library as part of its build, as they say it
> should be.
> - Irrlicht upstream should be convinced that this is a lousy way to use
> a library, and they should fix this to make the library run-time
> configurable so a single shared library package can be used.
TBH I'm really only maintaining irrlicht because supertuxkart depends
on it; I don't know enough about irrlicht to say whether or not this
is the right approach or if it could be done differently and "fixed"
in irrlicht somehow, hence I've taken everything that stk's devs have
said at face value. This is something I'll have to look into when I
have some more spare time...
> On the other hand, if STK does really fork the library (as opposed to
> just changing the header before compilation), there will really be two
> source packages, and they should be treated as such, I suppose.
>
>> >> 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.
>
> I would indeed rather go for "if it's this much trouble, I'll spend my
> time on something else instead", as Paul suggested.
>
> Thanks,
> Bas
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-games-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 50C76ECB.5060708@debian.org">http://lists.debian.org/[🔎] 50C76ECB.5060708@debian.org
>
Reply to: