Matthias Saou wrote:
Michael Thomas wrote :
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Quick comment : You should add the "= %{version}-%{release}" to the
"Provides:" in your document.
Fixed.
Otherwise, Tcl seems completely broken when it comes to multilib... [1]
and you seem to be aware of the major issues as the TODO section shows.
But it contains tasks so critical that I wouldn't bother trying to push
these packaging rules forward until they are taken care of. For
instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4"
symlink with a real directory is... errr... pretty much impossible for
rpm to do. You might be able to hack around it, but it'll be ugly.
Good luck! :-)
Matthias
[1] https://bugzilla.redhat.com/228177
Yes, multilib is broken in Tcl, partially because of the symbolic link
from /usr/lib/tcl8.4 -> /usr/share/tcl8.4. Even on x86_64, the link is
/usr/lib, not /usr/lib64. The tk spec file used to do the same thing,
but it was fixed by adding a scriptlet in %pre to remove the symlink:
[ ! -h %{_prefix}/%{_lib}/%{name}%{majorver} ] || rm
%{_prefix}/%{_lib}/%{name}%{majorver}
I presume the same could be done with Tcl.
There's really one main task that needs to be done before tcl extensions
could be modified for the new guidelines, and that is to add
%{_libdir}/tcl%{majorver} to the default package path. This is
trivially fixed by modifying one of the patches in the tcl package, but
I haven't been able to convince the Tcl maintainer to include it yet. I
think that this, along with the symbolic link problem, will fix the
multilib problem, since all arch-specific extensions will now be
installed into %{_libdir}/tcl%{majorver} instead of
%{_datadir}/tcl%{majorver}.
--Wart
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
