Bug 228175 - multi-lib conflicts
multi-lib conflicts
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gnu-smalltalk (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jochen Schmitt
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE7Target
  Show dependency treegraph
 
Reported: 2007-02-10 18:45 EST by Michael Schwendt
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-22 16:28:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2007-02-10 18:45:04 EST
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?
Comment 1 Paolo Bonzini 2007-02-12 03:24:27 EST
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
Comment 2 Michael Schwendt 2007-02-12 04:29:38 EST
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.
Comment 3 Paolo Bonzini 2007-02-12 04:43:10 EST
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.
Comment 4 Paolo Bonzini 2007-02-12 05:15:00 EST
Also, can you attach a diff for the Gtk files?  They should be the same.
Comment 5 Michael Schwendt 2007-02-12 05:40:32 EST
> 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
Comment 6 Paolo Bonzini 2007-02-12 05:59:44 EST
(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 11:51:49 EST
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.
Comment 8 Jochen Schmitt 2007-03-22 16:28:12 EDT
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.