Bug#334534: Patch from bug 307724 breaks Eclipse

[Loic Minier]

        Hi,

On Fri, Dec 16, 2005, Billy Biggs wrote:
>   I talked about this again with seb128 at UBZ.  I really think the
> right solution is for Debian to revert the change.  It's a really
> low-level X thing, and there is no good way for us to detect that it is
> fixed.  Changing the Eclipse code in our stable release, especially now
> that it is so widely tested and used, is really hard.
>   I can appreciate that the same is true for Debian.  However, in the
> Debian case, there are also lots of other distributions which are
> shipping unpatched versions (or, at leat differently patched versions)
> of GTK+.  Just in terms of re-introducing bugs - clearly the safer fix
> is to revert a Debian-specific patch applied to GTK+, rather than patch
> Eclipse for all distributions.

 We already had the discussion, and you saw by yourself that it was
 impossible to revert such a sensible change in a deeply frozen distro.

 There are 1629 packages depending on libgtk2.0-0 available to my Debian
 system, and this is excluding packages using libgtk2.0-0 indirectly, eg
 via Python or Perl bindings.  How many would be affected by such a
 reversal?  Is there anyway that we can at least get a count?
   The answer to these questions is probably that we have no way to
 measure the impact on such a huge number of packages, no-one can tell.
 Besides, even if we knew that reverting the patch would need patching
 of say 20 packages, there's *no* *way* the stable team is going to
 allow such a change for the sake of... Eclipse.  And this is only
 assuming that we can really fix the bug for other packages/applications
 from their point of view.  What if the application is written in python
 and we can't work around the gdk problems because the bindings aren't
 available?

 I'm afraid we should have detected this problem earlier in the stable
 release cycle.  Back then, this patch helped fixing a real bug across a
 number of applications, so it was interesting to include.

 All I can offer is that we work with upstream to get some "extra
 version" information in the API so that distros can include some
 package related information (eg the version of the package).

 Unless you have better ideas to solve the current situation than
 "revert this change in libgtk for Eclipse workaround code not to
 break", we're stuck.

   Cheers,
-- 
Loïc Minier <lool at dooz.org>