I was quite surprised to find that a SLES 11 package that does some graphics is incompatible with both Redhat and CentOS 5.5.

The dependency is libgio-2.0.so.0 and searching for it reveals that it is part of gtk and glib2 but only for the SuSE distros and its ilk. Or is it that someone has created a new, code breaking dependency in a newer release? (there is a hint in this site that glib2-2.17 has created the dependency while CentOS 5.5 uses glib2-2.12)

Now, if I were a software developer and I wanted to make sure that my customers have no issues whether they choose to use any Enterprise distro, what should I use or avoid to make them happy? I want high end graphics -- OpenGL or better.

Do you agree that it would be smart to avoid any dependency on libgio and any 3rd party products that use it since it is not available on both distros?

S.

GIO was added to Glib-2.15.0 back in 2007, is set to replace GnomeVFS in Gnome-2.22 and is not exclusive to one Linux distribution.


If you 'Requires: glib >= 2-2.20, libgio' you force people to violate what their Enterprise Linux distribution offers in terms of reliability and longterm stability. This may also break their support contract which they may or may not be inclined to do. On top of that you, IMO, become responsible for bug fixes and security updates to these dependencies which you should not do unless you can handle the liabilities arising from that and have the knowledge and time to maintain dependency releases yourself.

1 members found this post helpful.

Thank you unSpawn. That was very helpful. I had not picked up on a glib2 to Gnome relationship. glib = "Gnome"lib? I thought glib = "Graphics"lib. yum groupinfo "GNOME Software Development" does show it as glib2-devel, but it does not appear in "GNOME Desktop Environment".

Now I wonder why CentOS 5.5 -- which is less than a year old -- is still using glib2-2.12 when you point out that glib2-2.15 was released in 2007. As you say the Enterprise distros are conservative about adding new things for stability and reliability, but 4 years seems like a long time in this business.

I suppose I could try to build a new glib2 myself and keep it in a separate location, but I am guessing that other dependencies will appear and make this difficult or even an exercise in dependency hell. (I once tried to enable the scan function in my printer-scanner-copier combo, and ran into a circular dependency that had no solution: x depends on y version > N, y depends on z, z depends on v, v depends on y version < N.)

Red Hat offers a 10 year life cycle for RHEL. I doubt RHEL users would view 4 years as "seemingly long" in terms of ROI and such.


Not, wanting that, you do.