gnu-smalltalk - 2.3.2-4.fc7.i386 File conflict in: /usr/share/gnu-smalltalk/gtk/Structs.st /usr/share/gnu-smalltalk/gtk/Enums.st /usr/share/gnu-smalltalk/gst.im /usr/share/gnu-smalltalk/gtk/Funcs.st Packages with the same files: gnu-smalltalk - 2.3.2-4.fc7.x86_64 Files in /usr/share should be arch-independent. Why do the files differ on i386 and x86_64?
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.