I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893)
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Please let me know if I need to do anything to help get these draft guidelines adopted.
Thanks,
--Wart
Would it be possible to add a discussion of this draft to the agenda for tomorrow's packaging meeting? I'd hate for it to be dead in the water due to lack of interest.
--Wart
Michael Thomas wrote:
I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893)
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Please let me know if I need to do anything to help get these draft guidelines adopted.
Thanks,
--Wart
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Michael Thomas wrote:
Would it be possible to add a discussion of this draft to the agenda for tomorrow's packaging meeting? I'd hate for it to be dead in the water due to lack of interest.
Afaik, the PC is generally in favor of the proposal, pending official buy-in/support from the Tcl maintainer.
-- Rex
Michael Thomas wrote :
Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document.
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
Matthias Saou wrote:
Michael Thomas wrote :
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
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
On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote:
Michael Thomas wrote :
Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document.
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.
I thought about it and it might be best if this was done during the move to 8.5. That way you don't really have to deal with it, the first 8.5 package just has to use the new way.
Sander Hoentjen wrote:
On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote:
Michael Thomas wrote :
Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document.
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.
I thought about it and it might be best if this was done during the move to 8.5. That way you don't really have to deal with it, the first 8.5 package just has to use the new way.
Yes, the 8.5 upgrade might be the best time to make the change with the link. The other two items above it in the list in the guidelines can still be done pre-8.5, though, and would allow existing extensions to be migrated to these new guidelines ahead of the 8.5 release.
It would be nice to do the upgrade to 8.5 before F7, but upstream is not very responsive on giving updated estimates on the final 8.5 release date. :(
--Wart
Michael Thomas wrote :
Sander Hoentjen wrote:
On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote:
Michael Thomas wrote :
Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document.
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.
I thought about it and it might be best if this was done during the move to 8.5. That way you don't really have to deal with it, the first 8.5 package just has to use the new way.
Yes, the 8.5 upgrade might be the best time to make the change with the link. The other two items above it in the list in the guidelines can still be done pre-8.5, though, and would allow existing extensions to be migrated to these new guidelines ahead of the 8.5 release.
It would be nice to do the upgrade to 8.5 before F7, but upstream is not very responsive on giving updated estimates on the final 8.5 release date. :(
Actually, the "merge review" might be good for the change, and I see you're actively participating in it. I've made this bug depend on it, since I have "metakit" containing a tcl shared library which needs this fixed : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228177
Matthias
Matthias Saou wrote:
Michael Thomas wrote :
Sander Hoentjen wrote:
On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote:
Michael Thomas wrote :
Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document.
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.
I thought about it and it might be best if this was done during the move to 8.5. That way you don't really have to deal with it, the first 8.5 package just has to use the new way.
Yes, the 8.5 upgrade might be the best time to make the change with the link. The other two items above it in the list in the guidelines can still be done pre-8.5, though, and would allow existing extensions to be migrated to these new guidelines ahead of the 8.5 release.
It would be nice to do the upgrade to 8.5 before F7, but upstream is not very responsive on giving updated estimates on the final 8.5 release date. :(
Actually, the "merge review" might be good for the change, and I see you're actively participating in it. I've made this bug depend on it, since I have "metakit" containing a tcl shared library which needs this fixed : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228177
I took a closer look at the metakit bug, and it seems that it's partially a bug in metakit, because it's using a hardcoded path to /usr/lib/tcl8.4 as its installation directory. I updated the bug report with additional notes on a workaround.
Tcl's multilib support isn't actually broken, because it already looks for extensions in %{_libdir}. Only extensions that install into %{_libdir}/tcl8.4 will be broken for multilib, but they will have other problems because %{_libdir}/tcl8.4 isn't in Tcl's package path on x86_64 anyway.
I'm glad you brought up the multilib issue, though. It's something that I hadn't considered, and is something that _will_ be broken by the draft guidelines until that symlink is removed. I've updated the guidelines to reflect that the symlink removal is now a _must_ item to fix.
As I see it now, in order to adopt the draft guidelines, Bugs #227725 and #227200 need to be fixed.
Is the merge review the correct place to fix these bugs?
Would it be better to wait for Tcl 8.5, when many extensions will have to be rebuilt anyway?
Should any of this be fixed in time for F7? (I think so)
Are these questions better suited for f-m-l instead?
--Wart
Wart wrote:
As I see it now, in order to adopt the draft guidelines, Bugs #227725 and #227200 need to be fixed.
Is the merge review the correct place to fix these bugs?
Would it be better to wait for Tcl 8.5, when many extensions will have to be rebuilt anyway?
Should any of this be fixed in time for F7? (I think so)
Are these questions better suited for f-m-l instead?
These last few questions, yes, imo.
-- Rex
Michael Thomas wrote:
Sander Hoentjen wrote:
On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote:
Michael Thomas wrote :
Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document.
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.
I thought about it and it might be best if this was done during the move to 8.5. That way you don't really have to deal with it, the first 8.5 package just has to use the new way.
Yes, the 8.5 upgrade might be the best time to make the change with the link. The other two items above it in the list in the guidelines can still be done pre-8.5, though, and would allow existing extensions to be migrated to these new guidelines ahead of the 8.5 release.
Now that Tcl 8.5 has been released and build (but not yet pushed, it seems) for Rawhide, I'd like to resurrect the Tcl packaging guidelines proposal. Is there anything more I can do in order to move forward on this?
--Wart
packaging@lists.fedoraproject.org
-
Matthias Saou -
Michael Thomas -
Rex Dieter -
Sander Hoentjen