Re: GtkModule fixes

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> > The one issue here is the one of "packages should not install outside there
> > own prefix". How does a user install GLE in /opt if GTK+ is installed 
> > in /usr, and /usr mounted read-only?
> 
> well, basically there's not much to install for GLE besides the actual .so
> anyways, so what's the users point in wanting to install it into /opt
> when gtk lives in /usr in the first place?

Because 

 a) /usr isn't writeable (you aren't root, or /usr is mounted readonly)
 b) You have a policy that you dont' install anything in /usr that
    doesn't come with the system. 

> if we'd want to, in this case, have GLE install itself into
> /opt/lib/gtk-2.0/GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE)/modules
> it probably needs a way to tell the instaleld gtk to look into that
> directory for modules as well.
> i don't think we invented a new problem here however, how are such things
> handled with compliance to fsstnd for other packages? say xmms with
> all the add-on modules that can be installed?

Well, the fssstnd is unlikely to say anything about this ... it's
really about where system vendors should put things. And system
vendors will put things in the standard location.

I think a path environment variable works fine ... the only question
is how you handle versioning. Is it:

 GTK_MODULE_PATH=/opt/lib/gtk-2.0/

And then we look into GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE)/modules
inside each path element? This would require a pkg-config variable
for GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE).

I wonder if we should turn things around and use:

 /opt/lib/gtk-2.0/modules/GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE)

instead ... the intermediate location for the version is rather odd
for a path.

Regards,
                                        Owen