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.
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.
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.
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.
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.
Updated summary to reflect that this is part of a more serious multilib problem with Tcl.
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?
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 ?
(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.
the problem from comment #6 is fixed by tcl-8.4.13-14
Could I close it finally or have you some other issues, which has to be solved as a part of this bug?
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.
Ok, I cleaned spec file from this mess. Changes like auto_path should be fixed in tcl8.5.
fixed in tcl-1:8.5.0-6