Hi, [EMAIL PROTECTED] wrote: > Graham Cobb wrote: >> More and more applications cannot be built for Maemo just >> because they use features in glib introduced after 2.12.12. > > Personally I consider this a mistake of those programs. And I also > believe you're wrong.
For information, the new APIs added in glib between 2.12.x and 2.16.x are: (from http://mail.gnome.org/archives/gtk-list/2007-August/msg00017.html) GRegex - an implementation of Perl regexes GSequence - a list that is implemented using a balanced binary tree g_get_user_special_dir() support for xdg-user-dirs (from http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00022.html) GIO - a replacement for GnomeVFS (along with gvfs, which has the back-end implementations) GChecksum - a utility to provide a central implementation of hash algorithms such as MD5, SHA-1 and SHA-256. 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. > A properly versioned operating system should be able to handle side by > side libraries. > > Windows can do this, libssl can do it, and gecko can do it. > > Unix is supposed to be able to do it. If Debian can't (which it clearly > can, see libssl), then that's a bug beyond the scope of maemo. 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? 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. >> Don't forget: the community CANNOT update glib -- Nokia prevent that. > > The community may not be able to replace: > /usr/lib/libgobject-2.0.so.0 > /usr/lib/libgthread-2.0.so.0 > /usr/lib/libglib-2.0.so.0 > /usr/lib/libgmodule-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 > > (1400.0 is a random number, I believe the only number that's restricted > is 1200.12.) > > 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? Or is there an application like ld.so.conf which needs to be run to update symlinks? > I'd be curious to see a list of applications that require newer glibs. > That seems kinda strange to me. I imagine it would be a list of applications plus version numbers, and would perhaps include applications targeting GNOME 2.20 and later. I did a little experiment on my recently updated Ubuntu 8.04 laptop: Generate list of installed packages: dpkg -l | awk '{print $2}' > package_list For each package, see if it depends on glib, and print the name of the package afterwards: while read package; do dpkg -s $package | grep Depends | grep 'libglib2\.0-0' >> glib_dependencies; if [ $? = 0 ]; then echo "Package: " $package >> glib_dependencies; fi; done < package_list Isolate the glib dependency: sed 's/^\(Depends: \).*\(libglib2\.0-0[^)]*)\).*/\1\2/g' < glib_dependencies > glib_dependencies_2 For each package, if the required version is greater than 2.12, print the name of the package: sed -ne '/^Depends.*2\.1[3456]/{n;p;}' < glib_dependencies_2 Try it for yourself. This should also work on 7.10. To print out the required version in addition to the package name at the last step, just change the "n" to "N" in the curly brackets. The results for me were that most GNOME applications on my system are consuming 2.14 or 2.16 glib interfaces. Of course, these are the full desktop versions, and not the maemo ports. Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
