Re: GNOME Namespace Management - ARC & GNOME

[Sander Vesik <sander_traveling yahoo co uk>]

 --- Owen Taylor <otaylor redhat com> wrote: 
> On Thu, 2004-12-16 at 01:36 +0000, Sander Vesik wrote:
> 
> > > What I've been trying to figure out is how far Suns
> > > commitment extends: take the example of GObject construct only properties.
> > > Would ARC have let this change through, if glib was written by
> > > Sun?
> > > 
> > 
> > Provided I'm not confusing the change with some other - it would have cause glib
> > library major bump so instead of libglib-2.0.so.0 there would now also be
> > libglib-2.0.so.1 with the .0 version being available for a long time. And this
> is
> > not even close to somehow Sun sopecific - you change ABI, you bump the shlib
> version
> > so 
> > that you can parallel install for applications that need it. 
> 
> I'm getting annoyed with this example; let me emphasize that there are
> really objects out there that fall apart all over the place if you
> change construct-only arguments after construction. The fact that 
> a check for G_PARAM_CONSTRUCT_ONLY had been missed was serious bug.
> 
> Complete bug compatibility means that you don't change anything ever
> with the same soname. Users end up with a mix of GTK+-2.0, 2.2, 2.4, 2.6
> apps on their system, each which have slightly different menu behaviors.
> The GTK+-2.0 app doesn't have antialiased fonts. Certain strings
> misrender in some of the apps because they are using older versions of
> Pango. 

So what? Its the application / system vendors  call to make, not *YOURS*. 
Because they actually know how it all will be used and what behaviour is 
desired. 

> 
> Let's not mention the fact that that you need to bump the soname
> of every other library that depends upon GLib when you bump the soname
> of GLib. We've had enough problems with apps that end up linking
> to both glib-1.2 and glib-2.0. Starting bumping the soname within
> the 2.x series...
> 

And back here in the real world, apps constantly break because of a lacking 
recompile after upgrading gnome. 

> Bumping the soname is simply not even worth considering. The only
> possible solution would have to been not to fix the bug. Realistically,
> backwards compatibility is never black-or-white. What fixes one app
> breaks another. When we become aware of a backwards compatibility issue
> caused by a bug fix or feature addition, we consider a range of factors:
> 

Realisticly, nobody gives a shit because they already ship a private version 
of libs they need or recompile everything from scratch. One would only rely 
on compatibility if they were completely out of their minds or were feeling really
sadistic about their QA and support people. There is no point in even discussing 
compatibility if the goal isn't an actual reusable and stable platform. 


=====
Sander

.sigless


		
___________________________________________________________ 
Win a castle for NYE with your mates and Yahoo! Messenger 
http://uk.messenger.yahoo.com