Bug 227200 - Tcl multilib broken - libdir macro not used
Summary: Tcl multilib broken - libdir macro not used
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: tcl   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 226893
TreeView+ depends on / blocked
 
Reported: 2007-02-03 12:36 UTC by Sander Hoentjen
Modified: 2008-01-18 08:18 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-18 08:18:50 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)
Patch to update package search path (494 bytes, patch)
2007-02-07 20:05 UTC, Wart
no flags Details | Diff

Description Sander Hoentjen 2007-02-03 12:36:07 UTC
Description of problem:
The tcl package doesn't use %{libdir}, but %{prefix}/lib
This causes packages that do use libdir to not be found in a "package require".


Version-Release number of selected component (if applicable):
tcl-8.5a5-6.fc7

How reproducible:
always

Additional info:
Michael Thomas is working on Tcl Packaging guidelines:
http://fedoraproject.org/wiki/MichaelThomas/Tcl
It would be great if you could also have a look there.
There is one issue raised:
"The symlink from %{tcl_sitearch}  to %{tcl_sitelib}  should be replaced by an
actual directory to properly separate the arch-specific and noarch extensions.
(needs investigation to see what might break)"
I think this should be done right now, because the switch from 8.4 to 8.5 is the
right time to do this. Otherwise there is no good way of doing it: some package
installs into %{tcl_sitearch}, the switch is made from symlink to dir, and
suddenly the files that are owned by the package have disappeared (from the view
of that package)

So in short I think it is important to fix this issue asap. It might cause some
breakage, so it is important to write to the maintainers list announcing the change.

Comment 1 Wart 2007-02-03 18:07:41 UTC
Adding %{tcl_sitearch} to the default search path can be done relatively easily
by modifying tcl8.3.5-tclConfig-package-path-90160.patch.

With regards to the symlink, there is a comment in the tcl.spec file:
# backward compatible symlink for legacy tcl packages that hardcode lib path
# to prefix/lib/%{name}%{majorver}
## make /usr/lib for multilib archs
mkdir -p %{buildroot}%{_prefix}/lib
ln -s %{_datadir}/%{name}%{majorver} %{buildroot}%{_prefix}/lib/%{name}%{majorver}

If these legacy tcl packages are Fedora packages, then they should be patched to
use %{_libdir}/%{name}%{majorver} instead of %{_prefix}/lib/%{name}%{majorver}.
 If you know which ones they are then I'd be happy to file bug reports and
patches to help them get fixed.

Comment 2 Wart 2007-02-06 17:52:58 UTC
There are really two issues here:

1) Remove the symlink and replace it with a real directory:
mkdir -p %{buildroot}%{_libdir}/%{name}%{majorver}
mkdir -p %{buildroot}%{_datadir}/%{name}%{majorver}


The Tcl packages that will need to be fixed are the ones that also use
%{_prefix}/lib as an installation directory, since %{_libdir} != %{_prefix}/lib
on x86_64.  This asymmetry also helps find which packages need the fix:  Look at
the contents of the x86_64 versions of the packages and see if any of them
contain files in /usr/lib (as opposed to /usr/lib64).

2) Add %{tcl_sitearch} (== %{_libdir}/%{name}%{majorver} aka
/usr/lib{64}/tcl8.5) to the default package search path

Extending the package search path is a necessary first step before bug #226893
can be addressed.

Comment 3 Wart 2007-02-07 20:05:45 UTC
Created attachment 147590 [details]
Patch to update package search path

This patch replaces the existing tcl8.3.5-tclConfig-package-path-90160.patch to
add %{_libdir}/tcl8.5 to the package search path.  No paths are removed from
the package search path.

Comment 4 Wart 2007-02-27 17:38:07 UTC
It was recently pointed out to me that this causes a multilib problem with Tcl.
 That is, due to both the symbolic link and from /usr/lib/tcl8.4 ->
/usr/share/tcl8.4, and the missing %{_libdir}/tcl8.4 from the package path, it
is not possible to have both the i386 and x86_64 versions of Tcl installed at
the same time, nor is it possible for any of the binary extensions.

See https://www.redhat.com/archives/fedora-packaging/2007-February/msg00274.html
for the discussion.

Comment 5 Wart 2007-02-27 17:52:11 UTC
Updated summary to reflect that this is part of a more serious multilib problem
with Tcl.

Comment 6 Sander Hoentjen 2007-03-18 10:57:15 UTC
when yum updating tcl now:
Running Transaction
  Updating  : tcl                          #########################
[1/2] 
error: unpacking of archive failed on file /usr/lib64/tcl8.4: cpio:
rename

Updated: tcl.x86_64 1:8.4.13-13.fc7
Complete!

I think the problem is because in the specfile there is:

mkdir -p $RPM_BUILD_ROOT/%{_prefix}/lib
ln -s %{_datadir}/%{name}%{majorver} $RPM_BUILD_ROOT/%{_libdir}/%{name}%{majorver}

the top line should have libdir too, right?

Comment 7 Marcela Mašláňová 2007-03-20 12:49:44 UTC
The top line is here for making /usr/lib even on x86_64 system.

I install packages with 'rpm -Uvh' without warning. You was upgrading from
tcl.x86_64 1:8.4.13-12.fc7 to tcl.x86_64 1:8.4.13-13.fc7 ?

Comment 8 Sander Hoentjen 2007-03-20 17:38:03 UTC
(In reply to comment #7)
> The top line is here for making /usr/lib even on x86_64 system.

But it shouldn't be there on x86_64, or am i missing something?
> 
> I install packages with 'rpm -Uvh' without warning. You was upgrading from
> tcl.x86_64 1:8.4.13-12.fc7 to tcl.x86_64 1:8.4.13-13.fc7 ?

# rpm -Uvh /var/cache/yum/development/packages/tcl-8.4.13-13.fc7.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:tcl                    ########################################### [100%]
error: unpacking of archive failed on file /usr/lib64/tcl8.4: cpio: rename
failed - Is a directory
[root@peecee ~]# rpm -q tcl
tcl-8.4.13-12.fc7

i cleared my cached and tried again but got the same problem.

Comment 9 Sander Hoentjen 2007-03-30 08:33:09 UTC
the problem from comment #6 is fixed by tcl-8.4.13-14

Comment 10 Marcela Mašláňová 2007-04-02 12:19:48 UTC
Could I close it finally or have you some other issues, which has to be solved
as a part of this bug?

Comment 11 Sander Hoentjen 2007-04-02 13:22:15 UTC
couple of comments:
In you spec you have:
mkdir -p $RPM_BUILD_ROOT/%{_prefix}/lib
I don't think it is being used, so it can probably go. (in the x86_64 package
there is nothing in that dir)

cp -Rp $RPM_BUILD_ROOT/%{_datadir}/%{name}%{majorver}/ $RPM_BUILD_ROOT/%{_libdir}/
this seems unnecessary, Why would you want to copy this? Choose one location
(%{_datadir}/%{name}%{majorver}/ seems to be the best, since there is no arch
specific stuff), and leave the other dir empty, but do let the package own it.

other then that, it seems /usr/lib is still in auto_path for my x86_64 tcl, this
seems wrong: if the package is non-arch specific it should go under datadir, if
not i would want the x86_64 version.

Comment 12 Marcela Mašláňová 2007-04-03 13:32:13 UTC
Ok, I cleaned spec file from this mess. Changes like auto_path should be fixed
in tcl8.5.

Comment 13 Marcela Mašláňová 2008-01-18 08:18:50 UTC
fixed in tcl-1:8.5.0-6


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