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