Bug 228177
| Summary: | metakit multi-lib conflicts | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | metakit | Assignee: | Matthias Saou <matthias> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | wart |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Added bug dependency on the actual Tcl multi-lib bug report (though it wasn't recognized as such at first). 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.
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. 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.
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. |
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