Bug 228175

The gtk/* files are automatically generated from the Gtk header files.

The gst.im file is different because it is a binary dump.  I would be inclined
to put it into /var/lib/smalltalk upstream, but Jochen Schmitt says it's a bad
idea.  

Is there some place in /var that is multilib-dependent? e.g. /var/lib vs.
/var/lib64?

Thanks,

Paolo

The files generated from GTK headers contain arch-dependent definitions
and are clearly wrong in /usr/share.

> gst.im

Contains a shell script header. Uh?

Is it arch-independent anyway? If made available via a
network file-system in a heterogeneous environment, can a big-endian
machine use it if it's exported from a little-endian installation?
Does it change at run-time? Is it read-only?

There is no /var/lib64. Instead, it sounds as if you need an
arch-dependent home directory.

I see.  I will move the GTK headers to the same directory as gst.im, but we need
to nail down where to move that one.

gst.im is an arch-dependent binary dump.  Big-endian can be loaded from
little-endian and vice versa, but 32-bit cannot be loaded from 64-bit and vice
versa.

By default, it is effectively readonly (it can be redumped easily, but if nobody
has write access to the directory where it is stored, nobody will be able to
redump it).  However, it may make sense, if the user wishes to do so, to make it
world writable.  In this case it would change at run time and would not be
readonly anymore.

> There is no /var/lib64. Instead, it sounds as if you need an
> arch-dependent home directory.

I don't really understand what you mean by "arch-dependent home directory".  I
guess it's some Fedora-specific concept.

What I wanted to do upstream (hence the request for /var/lib64) is:

  imagedir=`echo "$libdir" | sed \
                  -e 's,${exec_prefix},${localstatedir},' \
                  -e "s,${exec_prefix},\${localstatedir}," `
  AC_SUBST(imagedir) 

FWIW, I found on the web (http://www.mabula.net/tbfw/tech/fedora) a reference to
/var/lib64.

But I also found that in bug 176613 a package using it moved the file to /usr/lib64.

Also, can you attach a diff for the Gtk files?  They should be the same.

> arch-dependent home directory

Something like /usr/lib{64}/gnu-smalltalk
or /usr/lib/gnu-smalltalk/{i386,x86_64,ppc64}

> Also, can you attach a diff for the Gtk files?

If you don't trust the automated checksum check, verify it here:
http://fedoraproject.org/extras/development/x86_64/

> But I also found that in bug 176613 a package using it moved
> the file to /usr/lib64.

But /usr must be able to be mounted read-only. The core filesys
package does not include /var/lib64, but /var/lib.

$ rpmls -p filesystem-2.4.1-1.x86_64.rpm |grep 64
drwxr-xr-x  /lib64
drwxr-xr-x  /lib64/tls
drwxr-xr-x  /usr/lib64
drwxr-xr-x  /usr/lib64/X11
drwxr-xr-x  /usr/lib64/games
drwxr-xr-x  /usr/lib64/sse2
drwxr-xr-x  /usr/lib64/tls
drwxr-xr-x  /usr/local/lib64

(BTW, I do trust the automated checksum check, I just wonder what these
differences are for Gtk-files and whether I can eliminate them upstream).

Would /var/lib/smalltalk/{i386,x86_64,ppc64} be ok?  It would be relatively easy
for the Fedora package to override the choice made upstream, if I provide a
configure option.  I can backport the configure option to the 2.3.x release
series, even if I have to delay using /var upstream until 2.4.

I released 2.3.3 which has a --with-imagedir option.

I suggest you try compiling with --with-imagedir='${libdir}' and use
post-install commands to move the offending Gtk+ files to
/usr/lib/gnu-smalltalk/gtk from /usr/share/gnu-smalltalk.  It should work,
though I haven't tested it.

It's true that some people may want a writeable gst.im, but the situation with
/usr/lib will not be any worse than with /usr/share (i.e. the current Fedora
Extras package).

For 2.4 I will modify the default imagedir.  I still think I'll use a place in
/var, but I'm open to other suggestions -- anyway it would be pretty transparent
to you because --with-imagedir will be of course supported in 2.4 too.  I still
haven't thought how to address the problem with the Gtk+ files upstream.

Is this ok with you guys?  Thanks.

The current version of gnu-smalltalk should fix the problem. I have forgotten to
close this bug.