Re: Upcoming changes in Tcl/Tk packaging
Hi Matthias, On Wed, Sep 25, 2013 at 5:12 PM, Matthias Klose d...@debian.org wrote: Am 25.09.2013 14:52, schrieb Sergei Golovan: 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. would be nice to track these in some place. I've created two pages on the wiki: https://wiki.debian.org/Teams/DebianTclTk/UpgradeDefaultTclTkTo86 and https://wiki.debian.org/Teams/DebianTclTk/TclTk84Removal and started to report FTBFS bugs (with fixes if I can propose a fix). The first page contains more than just tracking upgrade to 8.6. It contains FTBFS due to various reasons, sometimes pretty unexpected. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOq2pXGPHJx=fyq3he8ftazz8kc14fyk4p1k+e1bequl15_...@mail.gmail.com
Upcoming changes in Tcl/Tk packaging
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): 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. 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and libtk8.5-dev respectively (the latter packages still provide the former as virtual packages to break as few packages as it could be). This change is not strictly necessary, but the new names follow the common convention for development libraries. Only 4 packages break because of this change. They either have versioned depends or build-depends on tcl8.*-dev or tk8.*-dev. (cableswig, netgen, tix, tkdesk). 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since too many packages have versioned build-dependencies on tcl-dev or tk-dev, I chose to retain tcl-dev and tk-dev packages (as meta-packages which depend on libtcl-dev and libtk-dev). Switching to libtcl-dev and libtk-dev can be gradual. Would adding a lintian warning discouraging to use the old names possible? And the last but the most significant change: 4. Dropping /usr/bin/tclsh and /usr/bin/wish alternatives. Currently, any tcl8.* package offers /usr/bin/tclsh and any tk8.* package gives /usr/bin/wish via alternatives mechanism. I want to drop it and provide /usr/bin/tclsh and /usr/bin/wish as symlinks in tcl and tk packages respectively (similar to python packages). This change is very invasive. It makes about 40 packages FTBFS, and I don't know how many packages will break silently. The problem is that currently packages which depend on tcl8.5 (or tcl8.4, or tcl8.6) assumes that /usr/bin/tclsh exists (and the same is for tk8.5 and /usr/bin/wish). Though for many of them (those which depend on tcl8.5 or tk8.5) the fix will be trivial - to change dependency to tcl or tk, which provide /usr/bin/tclsh and /usr/bin/wish symlinks. These changes will require revision for the Debian Tcl/Tk policy. The new draft isn't published yet. It's still preparing in SVN: svn+ssh://svn.debian.org/svn/pkg-tcltk/policy/trunk (Is there anonymous access to it?) So, I'd like to start reporting bugs on found FTBFS and #!/usr/bin/tclsh or #!/usr/bin/wish shebangs without tcl or tk dependencies. Then I'll upload the changed Tcl/Tk packages to unstable. 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). Any questions, comments. Anything I've missed? Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoq2pxggdhzwm0z8dgd3zqoaepjdtofbk9l29b13vrdu_f0...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hi Sergei, (replying to the first part only since it strikes me) Sergei Golovan sgolo...@nes.ru (2013-09-25): 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and libtk8.5-dev respectively (the latter packages still provide the former as virtual packages to break as few packages as it could be). This change is not strictly necessary, but the new names follow the common convention for development libraries. please don't. Renaming without having a reason is a bad idea, that means creating a lot of work for no benefit. (Besides having to adjust a few packages in unstable, which you mentioned already, imagine someone backporting her packages to previous releases, she gets to carry a diff because of “cosmetics”, which isn't nice.) 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since too many packages have versioned build-dependencies on tcl-dev or tk-dev, I chose to retain tcl-dev and tk-dev packages (as meta-packages which depend on libtcl-dev and libtk-dev). Switching to libtcl-dev and libtk-dev can be gradual. Would adding a lintian warning discouraging to use the old names possible? Same as above: creating work for no actual benefit. If that was triggered by some lintian warnings, just override them and be done with it. Lintian isn't here to generate work. Mraw, KiBi. signature.asc Description: Digital signature
Re: Upcoming changes in Tcl/Tk packaging
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? 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? 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? Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5242af5b.4080...@debian.org
Re: Upcoming changes in Tcl/Tk packaging
On 2013-09-25 11:38, Cyril Brulebois wrote: 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since too many packages have versioned build-dependencies on tcl-dev or tk-dev, I chose to retain tcl-dev and tk-dev packages (as meta-packages which depend on libtcl-dev and libtk-dev). Switching to libtcl-dev and libtk-dev can be gradual. Would adding a lintian warning discouraging to use the old names possible? Same as above: creating work for no actual benefit. If that was triggered by some lintian warnings, just override them and be done with it. Lintian isn't here to generate work. Mraw, KiBi. Actually, I think Sergi wanted to add a Lintian warning for using the old names (IANSergi, so it is just a guess). At least I am pretty sure Lintian does not have a tag for renaming -dev packages (the only thing I can think of is the pkg name does not match SONAME-tag, but it doesn't seem to apply here). FTR, that is pretty trivial to mark packages obsolete in Lintian. It simply requires adding the package names to the Lintian data file called data/fields/obsolete-packages. (Though, that is not a remark about whether the renaming should be done in this case) ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5242b354.5000...@thykier.net
Re: Upcoming changes in Tcl/Tk packaging
On Wed, Sep 25, 2013 at 5:39 PM, Matthias Klose d...@debian.org 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): Will there is a /usr/bin/tclsh8.6 like python? would it be possible to drop 8.4 first? 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? 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? Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5242af5b.4080...@debian.org -- YunQiang Su -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6X=+0Af6Bei1GrfSsGatzvHYUeJs6YzMYtm=afs4vv...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hello, On Sep 25, 2013 11:40 AM, Matthias Klose d...@debian.org wrote: Am 25.09.2013 10:25, schrieb Sergei Golovan: 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? Not many things. I'm aware of one package, but that's a bug in it, I just can't find enough time to patch it. In general Tcl/Tk upstream is very careful about changes, and it's very rare that compatibility breaks. Even ABI is kept very stable so usually you can use binary extensions from old Tcl versions with new ones.
Re: Upcoming changes in Tcl/Tk packaging
Hi Cyril, On Wed, Sep 25, 2013 at 1:38 PM, Cyril Brulebois k...@debian.org wrote: Hi Sergei, (replying to the first part only since it strikes me) Sergei Golovan sgolo...@nes.ru (2013-09-25): 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and libtk8.5-dev respectively (the latter packages still provide the former as virtual packages to break as few packages as it could be). This change is not strictly necessary, but the new names follow the common convention for development libraries. please don't. Renaming without having a reason is a bad idea, that means creating a lot of work for no benefit. (Besides having to adjust a few packages in unstable, which you mentioned already, imagine someone backporting her packages to previous releases, she gets to carry a diff because of “cosmetics”, which isn't nice.) You are right. The old names tcl8.5-dev and tk8.5-dev are not pretty given they accompany libtcl8.5 and libtk8.5, but fully replacing them by libtcl8.5-dev and libtk8.5-dev will take a lot of work. Okay, I'll return the old names for the -dev packages. 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since too many packages have versioned build-dependencies on tcl-dev or tk-dev, I chose to retain tcl-dev and tk-dev packages (as meta-packages which depend on libtcl-dev and libtk-dev). Switching to libtcl-dev and libtk-dev can be gradual. Would adding a lintian warning discouraging to use the old names possible? Same as above: creating work for no actual benefit. Nice package name is a benefit to me, though it might not exceed the costs of moving. If that was triggered by some lintian warnings, just override them and be done with it. Lintian isn't here to generate work. I meant a lintian warning which softly encourages to switch to libtcl-dev from tcl-dev. -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoq2pxf-wpfndlb53rseubndw_j9xosj0rjcf8xvtt+tkjz...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hi Matthias, On Wed, Sep 25, 2013 at 1:39 PM, Matthias Klose d...@debian.org 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 in /usr/lib. 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. -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoq2pxhjkrojuuaot1byntj2+85owihzrmp04xcdw_nati8...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hello, On 25 September 2013 14:52, Sergei Golovan sgolo...@nes.ru wrote: 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. When I have some free time, I occasionally port this or that package. Actually, I've created this page: https://wiki.debian.org/ReleaseGoals/UpgradeTcl and propose it as a release goal. -- WBR, Andrew -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacujmdnqgyb+qa7yny6a-t98t-vxfzoccuhkbpotojvqyd9...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
+++ Sergei Golovan [2013-09-25 12:25 +0400]:
Hi fellow developers,
I would like to introduce a few significant changes into Debian Tcl/Tk
packages.
Thank you for doing this work, and for this clear summary.
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.
Any questions, comments. Anything I've missed?
Yes, the other multiarch-related change needed in tcl is making
tclConfig.sh and tkConfig.sh cross-friendly.
This is not strictly tied to the above changes, but because
tclConfig.sh is arch-specific, and revdeps are affected by the other
changes it makes sense to fix this now whilst we are making a mess.
The existing (ubuntu) patches add a compat script at
/usr/lib/tcl8.6/tclConfig.sh which calls
/usr/lib/${DEB_HOST_MULTIARCH}/tcl8.6/tclConfig.sh
which enables backwards compatibility and will usually work, so long
as whatever called it really did want the host-arch version. Fixing
rdeps to actually call the arch wanted during the build is better
because it will always work. Providing triplet-tclConfig.sh links
would be consistent with the way this has been made config-system
friendly and distro-agnostic in other packages.
Migrating tcl to use pkgconfig instead would remove the need for this
to be arch-specific, which is an even better solution, but I don't
know how enthused upstream is about doing that.
So have you included this change too? Doing so does not require
revdeps changes so long as they only need the host arch version. We
could force them to actually choose the one they want by not including
the compatibility layer, but that seems like too big a hammer. There
are 246 packages that build-dep on {tcl|tk}(8.[456])*-dev
Some relevant bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698674
https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1164937
https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1122120
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631995
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703421
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130925150444.gb32...@stoneboat.aleph1.co.uk
Re: Upcoming changes in Tcl/Tk packaging
Hi Wookey,
On Wed, Sep 25, 2013 at 7:04 PM, Wookey woo...@wookware.org wrote:
+++ Sergei Golovan [2013-09-25 12:25 +0400]:
Hi fellow developers,
I would like to introduce a few significant changes into Debian Tcl/Tk
packages.
Thank you for doing this work, and for this clear summary.
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.
Any questions, comments. Anything I've missed?
Yes, the other multiarch-related change needed in tcl is making
tclConfig.sh and tkConfig.sh cross-friendly.
This is not strictly tied to the above changes, but because
tclConfig.sh is arch-specific, and revdeps are affected by the other
changes it makes sense to fix this now whilst we are making a mess.
The existing (ubuntu) patches add a compat script at
/usr/lib/tcl8.6/tclConfig.sh which calls
/usr/lib/${DEB_HOST_MULTIARCH}/tcl8.6/tclConfig.sh
Yes, I used changes from Ubuntu as a basis, so exactly this compat
script is included into (lib)tcl8.6-dev package.
which enables backwards compatibility and will usually work, so long
as whatever called it really did want the host-arch version. Fixing
rdeps to actually call the arch wanted during the build is better
because it will always work. Providing triplet-tclConfig.sh links
would be consistent with the way this has been made config-system
friendly and distro-agnostic in other packages.
What's triplet-tclConfig.sh links and how are they better then just
/usr/lib/triplet/tcl8.6/tclConfig.sh?
Migrating tcl to use pkgconfig instead would remove the need for this
to be arch-specific, which is an even better solution, but I don't
know how enthused upstream is about doing that.
I'm not sure if it's an option. There're tons of existing extensions
which use tclConfig.sh, many of them are abandoned and will never
migrate to pkgconfig, but they are still useful.
So have you included this change too? Doing so does not require
revdeps changes so long as they only need the host arch version. We
could force them to actually choose the one they want by not including
the compatibility layer, but that seems like too big a hammer. There
are 246 packages that build-dep on {tcl|tk}(8.[456])*-dev
I've included the compatibility script. You're right, requiring all
the packages to use /usr/lib/triplet/tcl8.6/tclConfig.sh is
impractical.
Cheers!
--
Sergei Golovan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOq2pXEKuw=yewtmjfqxchq9hpmpeobgtssbrs2km1g8sbm...@mail.gmail.com
