Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 228177 - metakit multi-lib conflicts
metakit multi-lib conflicts
Product: Fedora
Classification: Fedora
Component: metakit (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-02-10 18:50 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:
Last Closed: 2007-06-19 13:52:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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:50:42 EST
metakit -
  Conflicts: 1
  File conflict in:
  Packages with the same files:
     metakit -
Comment 1 Matthias Saou 2007-02-27 11:40:46 EST
Tcl is completely broken wrt multilib.

There is currently a draft here, which also highlights the fixes needed :

See also a discussion here :

I'm making this bug depend on the tcl "merge review" since they shoud be fixing
the multilib in it.
Comment 2 Wart 2007-02-27 12:39:19 EST
Added bug dependency on the actual Tcl multi-lib bug report (though it wasn't
recognized as such at first).
Comment 3 Wart 2007-02-27 14:09:48 EST
Metakit is part of the problem here as well.  In unix/configure.in line 63 there
is a case statement that contains a few hard coded paths to ${prefix}/lib.  It
looks like you can use the flag to specify a different path:

%configure --with-tcl=/usr/include,/usr/lib64/tcl8.4

But since /usr/lib64/tcl8.4 is not yet part of Tcl's default package path,
you'll want to use /usr/lib64 instead.

However, I don't disagree that Tcl still causes multilib problems for extensions.
Comment 4 Matthias Saou 2007-02-27 14:19:25 EST
Yes, metakit is partly broken, but I haven't looked at it too much yet since I
first saw that tcl wasn't currently in shape anyway.
Comment 5 Wart 2007-06-04 00:14:23 EDT
After looking at this some more, I have changed my mind and disagree that this
is a Tcl multi-lib bug.  Yes, Tcl does create a symlink from %{_datadir}/tcl8.4
to %{_libdir}/tcl8.4, but replacing the symlink with an actual directory (the
proper fix for Tcl) will still cause metakit to fail.  This is because metakit
installs into /usr/lib/tcl8.4, even on x86_64.  Even if Metakit installed into
/usr/lib64/tcl8.4 on x86_64, it would still be broken because %{_libdir}/tcl8.4
is not a valid package directory for Tcl extensions, and won't be a valid
directory until the Tcl packaging guidelines are adopted and Tcl is modified.

Regardless of what happens with Tcl, metakit needs to change the way it chooses
its installation directory as described in comment #3 in order to fix the
multilib issue.
Comment 6 Matthias Saou 2007-06-19 13:52:01 EDT
OK, I've moved the tcl files to a sub-dir of _libdir. I'm not entirely convinced
this is a good solution, but it should at least fix the multilib conflict, and
can be changed again if/when tcl itself gets changed.

I've only rebuilt a devel package (fc8), as I don't think it's worth pushing an
update for.

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