Re: Upcoming changes in Tcl/Tk packaging
On Wed, Sep 25, 2013 at 1:39 PM, Matthias Klose <email@example.com> wrote:
> Am 25.09.2013 10:25, schrieb Sergei Golovan:
>> Hi fellow developers,
>> I would like to introduce a few significant changes into Debian Tcl/Tk
>> packages. Some of them have quite significant impact on their reverse
>> dependencies which will need a transition, I think. The proposed
>> changes are already in the experimental branch, so anyone could try
>> and break things.
>> The changes are (I use Tcl/Tk 8.5 as an example, but the same changes
>> are applied to 8.4 and 8.6 as well):
> would it be possible to drop 8.4 first?
There are about 30 packages left which unconditionally depend on
tcl8.4 or tk8.4.
We have to do some research and find how to port them to 8.5 or 8.6.
>> 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5
>> package with libraries moved to /usr/lib/<triplet> and with common Tcl
>> code in /usr/share/tcltk/tcl8.5. The same is for Tk (libtk8.5 is the
>> new package name). This change doesn't cause any impact on the reverse
>> dependent packages.
> Is this just the shared library, or -dev and -dbg packages as well? Will it be
> possible to cross-build Tcl/Tk extensions?
-dev packages contain static libraries which go to the multiarch directory too.
Includes are the same for all arches. As for -dbg, I never tried to build them.
Though I wasn't quite right when said that multiarchifying is not
intrusive. In fact,
a few packages (3 at least) FTBFS because they try to find libtcl8.5.so
>> Also, current stable upstream Tcl/Tk version is 8.6.1, but I wouldn't
>> like to switch to it now because it'll complicate the process of
>> removing alternatives a lot. But later I'd like to have another
>> transition (switching to 8.6 as default Tcl/Tk version).
> Do you have numbers what will break with 8.6?
There are 17 packages which build when 8.5 is the default version but
fail to build
after switching to 8.6. Most of them are patchable, though I'm not
sure if they will
work properly after that.