Subject: Re: commit -- libglade support
From: Sam TH (sam@uchicago.edu)
Date: Thu Feb 08 2001 - 11:56:47 CST
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;"
> Sam, please, read the email in which a wrote a mini-faq. It's seems evident
> to me that you have not yet read this email, because
I have read the FAQ. I'll read it again. But it's unlikely to change
my opinion on the above points. AIX compile logs are going to change
my opinon.
>
> 1) I explain clearly that this feature is for gtk+ (it was not even tested
> in gnome). I explain that it's a great help to solve the inconsistency in
> our GTK+ dialogs.
>
As I said before, I had misunderstood you. The GNOME build is one
where we tolerate much more library dependence, and are less worried
about porting. This is because GNOME as a whole is less portable than
the AbiWord unix builds.
> 2) I said that *EVEN IF THE DEPENDENCY IS PROHIVITIVE*, it will be cool if
> it would remains in the tree until the lists dialog is finished.
This is fine with me, with the following two caveats:
1. You are willing to put the work in to back out the changes when
the list dialog is in a reasonable state.
2. This isn't going to take too long. Target date for freeze for
0.9.0 is in a couple weeks.
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.
sam th
sam@uchicago.edu
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
This archive was generated by hypermail 2b25 : Thu Feb 08 2001 - 11:55:42 CST