Bug 228177 - metakit multi-lib conflicts
Summary: metakit multi-lib conflicts
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: metakit (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-19 17:52:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Michael Schwendt 2007-02-10 23:50:42 UTC
metakit - 2.4.9.6-1.fc7.i386
  Conflicts: 1
  File conflict in:
     /usr/lib/tcl8.4/Mk4tcl/Mk4tcl.so
  Packages with the same files:
     metakit - 2.4.9.6-1.fc7.x86_64

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 :
http://fedoraproject.org/wiki/PackagingDrafts/Tcl

See also a discussion here :
https://www.redhat.com/archives/fedora-packaging/2007-February/msg00274.html

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/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 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.