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 228177 - metakit multi-lib conflicts
Summary: metakit multi-lib conflicts
Alias: None
Product: Fedora
Classification: Fedora
Component: metakit
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-10 23:50 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-06-19 17:52:01 UTC

Attachments (Terms of Use)

Description Michael Schwendt 2007-02-10 23:50:42 UTC
metakit -
  Conflicts: 1
  File conflict in:
  Packages with the same files:
     metakit -

Comment 1 Matthias Saou 2007-02-27 16:40:46 UTC
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 17:39:19 UTC
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 19:09:48 UTC
Metakit is part of the problem here as well.  In unix/ 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 19:19:25 UTC
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 04:14:23 UTC
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 17:52:01 UTC
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.