Subject: RE: commit -- libglade support
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Thu Feb 08 2001 - 12:11:39 CST
Martin wrote:
>
> On Thu, Feb 08, 2001 at 06:03:02PM +0100, Joaquin Cuenca Abela wrote:
> > Sam wrote:
> > >
> > > On Wed, Feb 07, 2001 at 02:53:48PM +0100, Joaquin Cuenca Abela wrote:
> > > > I forget about this one...
> > > >
> > > > if we build binaries with libglade support, it would be nice to
> > > add links in
> > > > the download page to libglade rpms, debs, etc... (ximian
> > > provides packages
> > > > for a good amount of platforms)
> > > >
> > >
> > > I didn't mention this earlier, because I thought (without actually
> > > checking) that this was just a UnixGnome feature. However, it appears
> > > to intorduce Gnome dependencies into the GTK version of AbiWord.
> > >
> > > For example, when I went to update parsons to be able to compile the
> > > gladeified dialogs, I got the following:
> > >
> > > The following NEW packages will be installed:
> > > libart-dev libglade0 libglade0-dev libgnome-dev libgnorba-dev
> > > libxml-dev libxml1
> >
> > with shows that you picked the packages with the gnome support...
>
> Actually, the command I typed was 'apt-get install libglade-dev'. It
> seems that something weird happened here. But that isn't the real issue.
>
> >
> > > This is just trying to install the development version of the
> > > libraries.
> > >
> > > Additionally, the glade runtime has a dependency on libxml. Given
> > > this, it seems there wouldn't be a point to still having expat.
> >
> > we have support for libxml-2, and libglade needs libxml-1 (but,
> yes, it when
> > glade upgrades to libxml-2 it may be a good argument to change
> the default
> > in the unix build from expat to libxml).
> >
>
> Introducing another library dependency, which not all users have.
> Currently, the Unix build of AbiWord has the following dependencies:
>
> the standard c library:
> libstdc++-libc6.2-2.so.3 =>
> /usr/lib/libstdc++-libc6.2-2.so.3 (0x40303000)
> libm.so.6 => /lib/libm.so.6 (0x40349000)
> libc.so.6 => /lib/libc.so.6 (0x40366000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> libdl.so.2 => /lib/libdl.so.2 (0x40021000)
>
> gtk
> libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4005e000)
> libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40182000)
> libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x401b6000)
> libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x401b9000)
>
> X11
> libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401dc000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401e4000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401f2000)
>
> libpng
> libpng.so.2 => /usr/lib/libpng.so.2 (0x40024000)
>
> zlib
> libz.so.1 => /usr/lib/libz.so.1 (0x4004f000)
>
> And neither libpng nor libz provide really *core* functionality (not
> that I would like Abi without them, but it would be conceivable). You
> are planning to add two new libraries to this, that would be
> *absolutely neccessary* to using Abi.
>
> > > Further, this is *not* available on all Unices. What's the current
> > > state of AIX packages for libglade? How about IRIX? We shipped both
> > > of those for 0.7.12.
> >
> > as expat when abiword picked it. The truth is that when
> somebody ports a
> > package, hi has to be smart enough to port his dependencies.
> It's has been
> > done before, and I don't see why libglade will be a difference.
> >
>
> I'm not sure what your first sentence was meant to be, but if it was
> "as expat was when abiword picked it up" then that isn't true.
> Exactly 1 patch was in the old version of expat, and exactly 2 are in
> the new version. Neither had to do with commerical unix (1 from be in
> both, 1 from win32 in the new one).
>
> As to your statement about porting dependencies, that's precisely my
> point. When you want to make something portable, you want to have a
> few dependencies as possible. And you don't want to depend on porting
> things that you can't port. If I had a host of commercial unices
> sitting behind me, I would be happy to work on keeping Glade up to
> date on all of them. But that isn't going to happen.
>
> > > Unless there are satisfactory answers to these problems (like the
> > > libglade maintainers promising that every release they make builds on
> > > every Unix we have a makefile for) I'm going to invoke another feature
> > > of the Apache voting system we've discussed, and veto this change.
> >
> > what feature? just wondering, what gives you the right to veto
> the change?
> > I would understand that if there are many +1 to kick this
> feature, it has to
> > be kicked, but this veto history is stupid.
> >
> > Do I have the right to veto your veto?
> >
>
> For clarification, the Apache voting system has a veto, where if one
> developer vetoes a change, that veto is final. To quote the apache
> page:
>
> "Changes to the code are proposed on the mailing list and usually
> voted on by active members -- three +1 (yes votes) and no -1 (no
> votes, or vetoes) are needed to commit a code change during a release
> cycle;"
ops, my fault. I've never seen that in action, so I was not aware. Sorry
for the flames.
> 1. You are willing to put the work in to back out the changes when
> the list dialog is in a reasonable state.
yes. I prefer to see the libglade issues solved, but if there are not
solved I (or Martin) will degladeify the dialog.
> 2. This isn't going to take too long. Target date for freeze for
> 0.9.0 is in a couple weeks.
if 0.9.0 is released before the lists dialog, of course I myself will leave
the libglade support (really it's just a matter of touch a bit the
makefiles, and to change a function).
>
> I realize that glade is cool, and that it makes people's lives easier.
> But we shouldn't sacrifice our #1 benifit, portability, for it.
-- Joaquin Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Thu Feb 08 2001 - 12:11:04 CST