[maemo-developers] Diablo, do we need a separate repository?

[From: josh.soref at nokia.com]

Graham Cobb wrote:
> More and more applications cannot be built for Maemo just 
> because they use features in glib introduced after 2.12.12.  

josh.soref at nokia.com wrote:
> Personally I consider this a mistake of those programs. And I also
> believe you're wrong.

Dave Neary wrote:
> For information, the new APIs added in glib between 2.12.x 
> and 2.16.x are:

appreciated

> (from 
> http://mail.gnome.org/archives/gtk-list/2007-August/msg00017.html)
> GRegex - an implementation of Perl regexes

It's always fun to ask just how pcre is your pcre impl. I work on a web
browser. Web browsers can't use pcre because the spec is way too
divergent from pcre. :)

> GSequence - a list that is implemented using a balanced binary tree

I can't imagine millions of applications suddenly using this feature,
although I could be wrong :).

> g_get_user_special_dir() support for xdg-user-dirs

iirc red hat's code for this was contributed to mozilla. But in the
maemo context, I'm not sure how valuable/important this is.

> (from
> http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00
> 022.html)

> GIO - a replacement for GnomeVFS (along with gvfs, which has the
> back-end implementations)

Right, this has been discussed before (I'm well aware of it)

> GChecksum - a utility to provide a central implementation of hash
> algorithms such as MD5, SHA-1 and SHA-256.

As with GSequence, I can't imagine this is used very often. Our
"platform" includes some version of openssl (see other parts of this
thread), and people could use that.

> A full list of the new symbols in 2.14 and 2.16 is here:
> 2.14: http://library.gnome.org/devel/glib/stable/ix09.html
> 2.16: http://library.gnome.org/devel/glib/stable/ix10.html
> 
> Aside from GIO, which has recently received a big push for GNOME
> applications, I don't know if these APIs are in widespread use.

That's pretty much what I'd expect.

> I'm afraid I don't get your point - are you suggesting that 
> the correct
> way to handle the issue is to install glib 2.16.x alongside 
> glib 2.12.12?

In short, yes.

> The GNOME developers are very careful to maintain ABI stability -
> normally, 2.16 is a drop-in replacement for 2.12, and you should not
> even need to recompile your applications.

This I understand. However there's a faulty assumption. There isn't any
original compilation of these applications for this platform.

As such, it should be possible to divert to alternate libraries during
the original compilation. (this could be facilitated by the
autobuilders.)

Fwiw, I mentioned something about a revert. This stuff is semi public
(albeit painful to browse as afaict the svn itself is closed):
http://www.mail-archive.com/maemo-commits@maemo.org/msg04926.html
http://www.mail-archive.com/maemo-commits@maemo.org/msg04973.html

> > The community may not be able to replace:
> > /usr/lib/libglib-2.0.so.0

> > However it could easily provide:
> > /usr/lib/libgobject-2.0.so.0.1400.0
> > /usr/lib/libgthread-2.0.so.0.1400.0
> > /usr/lib/libglib-2.0.so.0.1400.0
> > /usr/lib/libgmodule-2.0.so.0.1400.0

> > 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.

> Interesting - will the latest version of the library be picked up
> automatically at runtime by applications, or do they need a recompile?

See above, I was positing an original compile that picked a version.

> Or is there an application like ld.so.conf which needs to be run to
> update symlinks?

The alternate approach I mentioned of a secondary directory is something
which I'm assuming could be abused by playing with /etc/ld.so.conf

Note that on my device /etc/ld.so.conf has:
/usr/lib/microb-engine
/usr/lib/microb-engine/components

Which implies that packages are allowed to play with it to some extent
(I believe the fact that microb - which I work on - is playing with it
is probably a bug, but you can ignore that for now).

Afaict according to /sbin/ldconfig -v -N -X (as user, not root),
microb-engine will be searched first.

> I imagine it would be a list of applications plus version numbers,

Sure, obviously listing applications which had 20 versions that worked,
and an experimental version no one had ever heard of which happens to
require the library would be a bad idea.

> and would perhaps include applications targeting GNOME 2.20 and later.

Sure.

> I did a little experiment on my recently updated Ubuntu 8.04 laptop:

But you didn't indicate the result, such a tease :)

> Try it for yourself. This should also work on 7.10.

I actually just gave away my ubuntu 7.10 box yesterday.

> The results for me were that most GNOME applications on my system are
> consuming 2.14 or 2.16 glib interfaces.

Presumably for gio.
I will note that gio and this entire abi discussion was mentioned in
this mailing list many months ago. It shouldn't be a surprise:

http://www.mail-archive.com/maemo-developers@maemo.org/msg14331.html

Someone actually kindly provided a gio thing for you:
http://www.mail-archive.com/maemo-developers@maemo.org/msg14310.html

So if you're in a hurry to help people use gio on chinook/diablo, I'd
suggest you thank Philip Van Hoof and work on packaging it.

> Of course, these are the full desktop versions, and not the 
> maemo ports.

Of course. I know of one such application (baobab) which is trying to
move to gio. I know because I was trying to help paolo borelli a few
days ago.

fwiw, I'm not actually opposed to gio, however, mozilla (actually this
was probably Red Hat), Nokia (this is basically a couple of people in my
group, calling it Nokia is probably inappropriate) and myself have all
invested non-trivial (i.e., days or weeks instead of just hours) amounts
of time/money/effort in gnome-vfs (which I learned to hate; and, as I
said in the other thread, am glad to see go the way of the dodo). I'm
sure someone will eventually contribute gio for mozilla, but mozilla
runs on a number of platforms and I'm sure some don't include gio today
and probably won't before 2010, so I won't be rid of it for a while. 

the only system requirements I can easily find are
http://www.mozilla.com/en-US/firefox/system-requirements which currently
are for Firefox 2.0 and they don't list a glib requirement.
http://www.mozilla.com/en-US/firefox/system-requirements-v3.html is the
equivalent for Firefox 3.0, but I think it's wrong on a couple of
points. Do note that historically gnome-vfs in mozilla was an optional
component so if your system didn't support it, you could certainly use
mozilla.

Note that the reason I was working on gnome-vfs support most recently
for mozilla is because the maemo platform uses gnome-vfs to talk to
obex. Sadly, afaict this glue is closed. I'm having a hard time figuring
out if gio supports obex. If someone wants to perform a useful
experiment, setup glib2.x (a version w/ gio), void the seal on your
application manager and install it on your device. Try using a gnome
application to interact w/ a phone using gio. If it works, report that
it works. If it doesn't, find out why. Obviously if gio-obex doesn't
work well enough to replace the gnomevfs stuff used in chinook (or
diablo, which again is basically chinook) then that means that it really
isn't ready. http://opensolaris.org/jive/thread.jspa?messageID=211105
seems to indicate gnome 2.22 regresses whatever obex support might be
available (which is obviously not a good start).

The browser itself uses gnome-vfs for bookmarks w/ a psuedo datasource.
Afaiu, the rest of the platform uses gnome-vfs for smb and upnp access.
I suppose since gnome isn't actually removing gnome-vfs it isn't as big
of an issue, however from a qa perspective, it's a feature that would be
entirely untested for the platform, and qa will always refuse to allow
such an addition, even if some other qa says "oh yeah, it should work on
some entirely unrelated environment with much newer compilers and a
different memory architecture, and ... And ... And ...." OTOH, gnome
basically stopped supporting gnome-vfs, which means someone at Nokia had
to (this is still cheaper than porting all the applications to gio).
Someone just made a fix for something relating to gnome-vfs for me today
(* this may have been some other integration layer and not technically
gnome-vfs, but ...).

And again, the goal was for diablo to be compatible w/ chinook.... Using
a different glib w/ a totally different feature set means that it really
isn't.