Bug 227200 - Tcl multilib broken - libdir macro not used
Tcl multilib broken - libdir macro not used
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tcl (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
:
Depends On:
Blocks: 226893
  Show dependency treegraph
 
Reported: 2007-02-03 07:36 EST by Sander Hoentjen
Modified: 2008-01-18 03:18 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-18 03:18:50 EST
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 15:05 EST, Wart
no flags Details | Diff

  None (edit)
Description Sander Hoentjen 2007-02-03 07:36:07 EST
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 13:07:41 EST
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 12:52:58 EST
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 15:05:45 EST
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 12:38:07 EST
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 12:52:11 EST
Updated summary to reflect that this is part of a more serious multilib problem
with Tcl.
Comment 6 Sander Hoentjen 2007-03-18 06:57:15 EDT
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 08:49:44 EDT
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 13:38:03 EDT
(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 04:33:09 EDT
the problem from comment #6 is fixed by tcl-8.4.13-14
Comment 10 Marcela Mašláňová 2007-04-02 08:19:48 EDT
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 09:22:15 EDT
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 09:32:13 EDT
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 03:18:50 EST
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.