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 227200 - Tcl multilib broken - libdir macro not used
Summary: Tcl multilib broken - libdir macro not used
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: tcl
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact:
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2008-01-18 08:18:50 UTC


Attachments (Terms of Use)
Patch to update package search path (deleted)
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.