On Thu, 13 Mar 2003 04:48:57 +0100, Lubomir Sedlacik <salo@Xtrmntr.org>
wrote:
> > Please tell me if you can what exactly is broken and what patch I
> > might apply, if any.    
> 
> there are API changes in new libgnomedb which are incompatible with what
> Glade2 expects and this issue is resolved in the Glade2 cvs but no
> release was made since then (Julio Merino could tell you more about the
> issue since he talked about it with Glade2 developers).  so you can
> resolve the issue by looking what exactly needs to be patched in the
> currect pkgsrc version of Glade2.  Julio noted it as not worth the
> trouble and we decided to mark it as broken until new release of Glade2
> is out.  

Ah, "next release" is of Glade2, not NetBSD.  

Checking http://packages.debian.org/unstable/devel/glade-2.html, I find no
dependency on libgnomedb.  I don't doubt you or Julio :) but I'd like to
understand your assumptions better.  My suspicion is that a lot of gnome
stuff is being pulled in:

$ ./configure --help |grep gnome
  --disable-gnome         disable use of gnome
  --disable-gnome-db      disable use of gnome-db

Perhaps that could be turned off for the time being?  Or a non-gnome glade
package created?  That would lead to a very different set of Makefile
includes (and a much lighter set of dependencies).  

The Dia project uses GTK2 but not Gnome, and I at least don't need Gnome. 


I took our distfile and configured with the above (disabling) switches.  I
still needed scrollkeeper to configure, and libgail to run.  (Perhaps
libgail is implied by the gnome stuff, dunno).  The only oddity was that I
had to "export LD_LIBRARY_PATH /usr/X11R6/lib" because (I assume)
configure didn't assert a path to libtool for the X libraries.  I now have
Glade2 running.  

> as i mentioned before, you can use netbsd-1-6-1 pkgsrc branch
> if you really need to use Glade2 immediatelly.

Oh, no, I'd much rather go the hard way.  :)

> as for creating the fix, you can try to comment or remove the BROKEN
> line from Glade2 Makefile, build all prerequisite packages and wait for
> the build to fail.  then fetch the Glade2 HEAD from their cvs and try to
> fix the old version.  you can also just ask the Glade2 people when the
> new release is read :).

An alternative route: Debian uses "glade-2 1.1.3-6" which looks to be
0.0.1-6 higher than our distfile.  Any problem using that instead?  No
chance I'm just lucky, is there, like, maybe that's the "next release"
we're waiting for?  I could try substituting that distfile for ours and
see what shakes out.  Too late to start that tonight, though.  

I'm not particularly interested in engineering a patch to deal with the
binary incompatibility; that would be too big a distraction from what I'm
doing.  But if some combination of what I've described makes sense to
render the package unbroken, I'd be happy to do that.  

Thanks very much for your patient explanation, Lubomir.  

Regards, 

--jkl