[Debian GNUstep maintainers] Bug#558993: Subject: FTBFS: NSWindow.m:198: fatal error: method definition not in @implementation context

[Yavor Doganov]

В 13:33 +0100 на 02.12.2009 (ср), Gürkan Sengün написа:
> I'm sorry about this, but please go blame the gnustep developers for this.

I will (as I planned to do a few months ago when I noticed the
NSZoneMallocAtomic removal in a point release).  But no matter what they
do, we are the ones who are going to suffer and we are the ones to deal
with all sort of breakages.

(I am not sure why you feel offended -- my intention wasn't to blame you
at all; I was just pointing out that we can't manage on the long term to
handle problems like this, especially if they're introduced often and
discovered post-factum.  Think about the eventual runtime failures, too,
they certainly prevail over FTBFSes.)

> Besides, we have more bugs/problems if we don't upgrade.

We will upgrade (that's unavoidable now anyway).  I was talking about
transitions 1.18 -> 1.20 for -base and 0.16 -> 0.18 for -gui/-back; i.e.
tracking stable (even numbered) releases like usual.  If we'll have to
introduce Debian-specific SONAMEs (provided that we detect ABI breaks
prematurely, which is not trivial for Objective-C libraries, as you
know) for unstable micro releases and have library transitions fairly
often, the release team will really hate us.

> Nobody want's stoneage gnustep libs. People install GNUstep from source, is that
> what Debian meant to be? Make users and developers suffer by having to install 
> everything by them selves? I doubt.

Of course not.  But you and I cannot deal with an avalanche of RC bugs
just because we ought to ship the newest (unstable) core libraries.  So
there's a balance to strike.  (Let's take this discussion to our list
and gnustep-dev; I'll post something there soon.)