[Fedora-packaging] Tcl packaging guidelines proposal

[Wart]

Matthias Saou wrote:
> Michael Thomas wrote :
> 
>> Sander Hoentjen wrote:
>>> On Mon, 2007-02-26 at 20:13 +0100, 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.
>>>>
>>>> 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