studies about newer libglib on fremantle
 

GLib is 'software utility library'. Read more: https://en.wikipedia.org/wiki/GLib
--
On Fremantle we have
Installed: 2.20.3-1maemo5+0m5
which is pretty old (e.g. current Ubuntu is using 2.30.0-0ubuntu4)

There are applications which can't be (easily) compiled/ported to N900, because they use newer glib than we have.

GLib is open source, and every Maemo modifications can be put on newer version. But programs compiled against old version won't work with newer version (who confirms is this true with every programs?), but they must be recompiled. So, hard part will be closed parts of Fremantle. According to this list http://wiki.maemo.org/Fremantle_closed_packages there are 355 packages.

I put them to the sorted list, each name on own row -> closed_fremantle.txt

On the phone:
This is list of packages which prevent us to use newer libglib. Some of them can be replaced with open alternative, some are useless (and with luck(?) some will work against different version of glib).

When we have truly open Maemo5, this will happen, but it not seems short term plan.
------------------------
Another approach could be use parallel versions of glib, as far as I know, nobody have done this and it might be impossible. I once started 'rebranding' glib-2.26 to the new name, so package can be made and installed parallel, but it never really worked:
https://gitorious.org/clutter-for-maemo/glib-226

Even program X is compiled against new version, X can also use library Y, which is compiled against old version -> crash!
----------------
Third approach is make own glib which contains everything from old and new glib and programs compiled against either will work with it. (This approach is called "backport new features from new to the old"). It is possible there are modifications which can't exists in the same time. This will need (deep) knowledge about glib.
-----------------
GLib is licensed under LGPL, so it is legal to take (part of) it and bundle (compile statically) it inside GPL applications. Generally speaking statically linking is stupid (as we have so good dynamic linking), but could this work? Could this be automatic (=transparency to developer and user)?
---------------
Anything else?

Re: studies about newer libglib on fremantle
 

Wish portrait mode requestors were back to make fuss around this and similar problems. This could extend the life of our devices considerably, if all those devs out there concentrated on such probs we could really say: F Y Nokia.

EDIT: oh btw, CSSU devs are going to recompile every component (open source at least) as thumb2 is now possible, maybe those hundreds of components could be upgraded too? Would breathe new life for sure.

Re: studies about newer libglib on fremantle
 

I hate this new trend of shamelessly breaking the ABI and don't bothering to change the soname, as if there were a shortage of version numbers.
This page http://linuxtesting.org/upstream-tra...ions/glib.html tracks API and ABI changes and highlights problems. Look at the "API changes column", clicking a "x changes" link will show what those changes are and what the problem is (most cases are inserting a parameter in the middle of the stack in a function definition).

The new libs can be installed in a different path (say /opt/glib-2.30) and then you can use LD_LIBRARY_PATH tricks to make the program use that. To avoid the problem with old library Y linked to old X, you should also put a new Y there.

Re: studies about newer libglib on fremantle
 

I feel that efforts are better spent recoding closed source components and pushing for maintainers to recompile their old packages against a new GLib when the time has come, then making an unideal situation just more convoluted by making the new GLib and all libs compiled against it sit in a special folder.

Re: studies about newer libglib on fremantle
 

Fair point about the naming system.
@AapoRantalainen: Is there any reason to go against it?

@Mentalist Traceur
As for OSSing CSS packages, again, good point but one must assume that the OP has an interest in what a new GLib can offer...
@AapoRantalainen
If you've got the time and energy to port more recent libraries - great. There is a space issue on the N900 so best to have only one version installed at a time. Please ensure software that currently relies on existing libraries will run just fine with the update. I also hope this doesn't lead to requiring a recompile of all maemo5 packages because that isn't going to happen, so we'd have lots of crashes from a library mismatch!

Re: studies about newer libglib on fremantle
 

Please don't forget that there are also closed source applications from OVI that might not work with new version of GLib. I don't know if that could also affect WebOS games.

In my opinion, a complete move to a newer GLIB which breaks ABI and API compatibility is completely useless. We need to keep actual GLib and use new one only for rebuilt OSS packages using either naming or LD_LIBRARY_PATH tricks (please check this useful post)

Re: studies about newer libglib on fremantle
 

Please don't forget that there are also closed source applications from OVI that might not work with new version of GLib. I don't know if that could also affect WebOS games.

In my opinion, a complete move to a newer GLIB which breaks ABI and API compatibility is completely useless. We need to keep actual GLib and use new one only for rebuilt OSS packages using either naming or LD_LIBRARY_PATH tricks (please check this useful post)

Edit: Sorry, double posting due to connection issues.

Re: studies about newer libglib on fremantle
 

Seems this thread is now part in bigger concept than libglib only.
Question is: Will there be someday Maemo5-Fremantle without closed source packages?

case yes: Then it is possible to recompile everything. (Then issue is packages without maintainers who handle potential issues with new API.)

case no: a) Some preinstalled package can't be switched, no open alternative exists (technical). b) Some package in non-free extras is too good to be dropped and developer is not interested in to upgrade it (social). c) Some closed package in OVI is too good (social).

case who cares, there are nemo and debian: This discussion happens on TMO, so it is relevant.

----
Meanwhile waiting this FrEEmantle happening, there could be another newer version of libglib parallel with old one, installed to the opt (and hopefully working transparency to the user). Then developer can make decision which version to use. My opening post describes how this could be accomplished, but I'm still not know how hard any of those will be.

Re: studies about newer libglib on fremantle
 

Provided the closed graphics driver is probably not glib dependent, a completely OSS Fremantle is theoretically possible.

No idea about things like telephony framework, skype, etc.

Also while I tried to port a newer Clutter version to Fremantle some time ago, the glib version was one of the main blocking issues, preventing Clutter past 1.4 from running (together with some missing EGL header files). IIRC Hildon is currently using Clutter 0.8 so upgrading Clutter & making Hildon use the newer version might be also useful, while not easy.

Re: studies about newer libglib on fremantle
 

Once you start upgrading quite a few files, it becomes easier to simply port the Hildon stack to GTK3 and use the MeeGo dialer instead of trying to work with the crazy mess that is Maemo 5. (plus we'd be able to do crazy **** like use btrfs as root, run on armv7tnhl kernels, use wayland and systemd, etc.)
Has anyone at Nokia seriously looked at what they made and not said WTF? You have shell scripts using dbus holding the whole thing together!