Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 228175 - multi-lib conflicts
Summary: multi-lib conflicts
Alias: None
Product: Fedora
Classification: Fedora
Component: gnu-smalltalk
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jochen Schmitt
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE7Target
TreeView+ depends on / blocked
Reported: 2007-02-10 23:45 UTC by Michael Schwendt
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-22 20:28:12 UTC

Attachments (Terms of Use)

Description Michael Schwendt 2007-02-10 23:45:04 UTC
gnu-smalltalk - 2.3.2-4.fc7.i386
  File conflict in:
  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?

Comment 1 Paolo Bonzini 2007-02-12 08:24:27 UTC
The gtk/* files are automatically generated from the Gtk header files.

The 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

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



Comment 2 Michael Schwendt 2007-02-12 09:29:38 UTC
The files generated from GTK headers contain arch-dependent definitions
and are clearly wrong in /usr/share.


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.

Comment 3 Paolo Bonzini 2007-02-12 09:43:10 UTC
I see.  I will move the GTK headers to the same directory as, but we need
to nail down where to move that one. 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

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}," `

FWIW, I found on the web ( a reference to

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

Comment 4 Paolo Bonzini 2007-02-12 10:15:00 UTC
Also, can you attach a diff for the Gtk files?  They should be the same.

Comment 5 Michael Schwendt 2007-02-12 10:40:32 UTC
> 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:

> 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

Comment 6 Paolo Bonzini 2007-02-12 10:59:44 UTC
(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.

Comment 7 Paolo Bonzini 2007-02-13 16:51:49 UTC
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, 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.

Comment 8 Jochen Schmitt 2007-03-22 20:28:12 UTC
The current version of gnu-smalltalk should fix the problem. I have forgotten to
close this bug.

Note You need to log in before you can comment on or make changes to this bug.