On Tuesday 06 May 2008 13:32:34 [EMAIL PROTECTED] wrote:
> A properly versioned operating system should be able to handle side by
> side libraries.

Why on earth bother?  I am also not a DD but my understanding was that in 
Debian this was only done when some ABI change occurs and means an 
application can only work with either the old or the new version.  IIUC the 
Debian approach to this issue would just be to replace libglib-2.0.so.0 
(etc.).

> > It should ONLY be a testing issue to make sure glib is kept up
> > to date in every release and it should be Nokia policy to keep
> > it up to date unless it is discovered to break an application.
>
> Please don't make assertions about such things. Especially if they
> involve resources you don't control.

I certainly will make assertions about such things.  I am fairly confident in 
my assertion that this is only a testing issue -- no code changes required -- 
but feel free to correct me if I am wrong.  Note that I didn't say it was a 
*small* issue, just that it was a testing issue.  I will also continue to 
assert, as a customer and a member of the development community which helps 
Nokia be more successful by providing additional applications, that Nokia 
should be keeping all system libraries up to date and should be scheduling 
testing, to verify that the updated libraries do not break anything, as part 
of the release cycle.  It is part of Nokia's responsibilities to its 
development community.

> That said, to some extent people obviously do want to use later versions
> of libraries when/where possible. No one loves the idea of using code
> that's many years out of date with its ever growing set of known bugs.
> However sometimes bug-wise compatibility triumphs.

During the life of an installed release, I agree.  Between Nokia-issued 
firmware releases, I disagree.  My view (I realise you disagree) is that at 
each new release Nokia should update all shared libraries.

> If it felt like it. While this would mean you'd have multiple glibs on
> the system, it isn't impossible to do, and if you absolutely need it,
> you could do it.

Sure, I could do that.  I could also build my own tablet or move to another 
product.  But my goal is to make a particular piece of software (e.g. 
Opensync) run on the tablet.  The barrier of creating my own glib package, 
(and trying to co-ordinate a community effort to use it so we don't all have 
to do the same thing), just to workround a Nokia restriction, may just raise 
the bar beyond the level I am willing to take to proceed with the project.  

To take a real example, I previously supported Opensync on mistral, gregale, 
bora and chinook.  I have already abandonned support for all except chinook 
because it was too much effort to deal with the old glib versions.  For the 
moment I persevere with chinook, patching Opensync to make it work with 
2.12.12.  One day even that will become too hard, at which time Opensync on 
Maemo will die unless Maemo includes an up to date glib.

I am hopeful that Nokia believes it is in Nokia's interest to provide some 
level of support for the community.  That should include not frustrating 
community efforts to port software.  If Nokia really want to stay on an old 
version of glib (or any other library) they should take the hit of creating 
their own libraries, not the community (which is why I suggested nokiaglib).  

> And no. I'm not a DD, my advice does not constitute Debian advice. I'm a
> pragmatist and a hacker. If I need something, I make it work.

If the "community" is to solve the problem I think it would be easier just to 
develop a patch to disable the Application Manager preventing updates to 
system libraries (and get rid of that annoying click-through warning while we 
are at it!).

> I'd be curious to see a list of applications that require newer glibs.
> That seems kinda strange to me.

Nothing strange at all.  Glib continuously adds new functions.  The whole 
purpose of Glib is to be a library of useful functions.  People use them.  

Nokia taking the benefit of using opensource code while deliberately making it 
hard for other projects to make use of the same benefit seems unreasonable.  
I believe Nokia has three feasible course of actions: 1) make sure system 
libraries are kept reasonably up to date; 2) use private libraries and let 
the community use bleeding edge libraries if we want; 3) turn off the locks 
preventing the community from updating system libraries.  Personally I prefer 
1 (because we all benefit from core system libraries not changing underneath 
us and can concentrate re-testing on OS updates), then 2 (the locks on system 
libraries do help with stability).

Graham
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Reply via email to