Subject: RE: commit -- libglade support
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Thu Feb 08 2001 - 11:03:02 CST
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...
> 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).
> 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.
> 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?
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
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.
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.
-- Joaquin Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Thu Feb 08 2001 - 11:02:33 CST