Re: glib-1.3

[Josh MacDonald <jmacd CS Berkeley EDU>]

I did have GQueue code in librepo for a long time when glib-1.2 
was still HEAD, then as soon as glib-1.3 appeared I fixed things because
I did not anticipate that over a month later there would still not be
a 1.3 glib available.

I don't like to look backward, and even though I understand the problems
that arise from the use of development versions, they are not my problems--
they are GIMP and GTK and GNOME and Mozilla problems.  As things stand
now, I can contribute to glib but I cannot use my changes for up to 6
months later!  That is absolutely ridiculous (think "cathedral"--because 
glib's false dependencies on GTK's development make it effectively that).  
Why should I use glib if I cannot improve it and make use of the improvements?  
Clearly someone should fix the problem (library dependencies) instead of 
the current symtomatic relief which is causing me pain.  That is a task for 
the automake and libtool groups, as far as I can tell.  If this situation 
doesn't improve, I will just create a new library, rename it and its symbols 
something else, and include it with all of my programs.  The problem will be 
solved, but at what a cost.  Yes, I _can_ make an autoconf test for the 
missing features in 1.2, but I've been having this problem for 1.5 years and 
I'm tired of it making extra work for me.  Putting an autoconf test for 
GQueue will only fix the problem until there's some new feature in glib-1.5 
that I can't use until GTK-1.6 is released, and so on.

-josh


Quoting Miguel de Icaza (miguel@nuclecu.unam.mx):
> 
> > Why should people have to recompile everything every 2 months?
> > I don't see it.  
> 
> I think this is from the bitter experience we had on the GNOME
> project.  Basically, by using the development versions of the
> libraries, we managed to effectively decrease our user base close to
> what most western cultures call zero.
> 
> Look at the complaints of people: when they installed GNOME themselves
> they lost access to the GIMP.  Yes, we can work around this.  No, it
> is not trivial to work around it and most Unix users will have a hard
> time getting this right.
> 
> > This conflict is a serious problem for us, because we're all working
> > in the same territory and our goals overlap.
> 
> I do not see why it is such a big deal.  You can just autodetect if
> glib has support for the GQueue and if not, use a version you supply
> in your code.  Just like any other AC_CHECK_FUNC()ed thing you put in
> your configure.in script.
> 
> > I do not see why development versions should not be made available,
> > in fact I don't see any problems at all except for the soname
> > business.
> 
> I do not think anyone has argued that the devel versions should not be
> made available.  
> 
> It just happens to be a non-supported platform for at least the
> Gnome/Mozilla combination.  
> 
> I am particularly worried because I want to use your code for Bonobo,
> and I need to make Bonobo work with the *stable* versions of the
> libraries.  
> 
> > I may just decide to release a version of glib named something else,
> > or with a different soname, but does it really have to come to that?
> 
> I wont be able to use your stuff in this condition.
> 
> Paraphrasing you: "I might just decide to release a version of librepo
> named something else, or with a different soname, but does it really
> have to come to that"?
> 
> I think all of our differences can be solved with a simple autoconf
> test.
> 
> Best wishes,
> Miguel.
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.

-- 
-josh