[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

tk vs tkstep


 recently I compiled a program which needs tk4.2. So I looked a bit deeper
 in the installation of tk/tkstep on my Debian systems. I had the latest Debian
 version (tk4.2_4.2p2-7) installed as well as the current versions of
 tkstep4.2 (4.2p2-5), tk8.0 (8.0.4-2) and tkstep8.0 (8.0p2-3.3).
 update-alternatives complains (update-alternatives --auto wish) about a
 problem with slave links for wish8.0 and its man page wish8.0.1. This is
 because tkstep8.0 installs these slave links, although there are binaries
 of the same name in the same location from tk8.0. tkstep4.2 doesn't do
 something like that for tk4.2.

 If the behaviour of tkstep8.0 is correct, it should conflict with and
 replace tk8.0.

 Furthermore, for tkstep (either 4.2 and 8.0) there's an additional entry
 /usr/lib/tkstep in ld.so.conf. However, this way the library libtk in
 this tkstep directory is always found before the libtk library in
 /usr/lib, and therefore tkstep libraries hide tk libraries. I think, there
 should be alternatives used for libtk too (not only for wish), but I'm not
 sure if this is "allowed" for libraries by policy (it's not forbidden
 explicitely, I think). Otherwise tk and tkstep should always conflict with
 each other and replace each other.

 The fact, that both tkstep4.2 and tkstep8.0 in their prerm scripts remove
 the directory /usr/lib/tkstep from /etc/ld.so.conf is somehow related to
 this issue. It could probably be solved by alternatives for the library.
 However, since for current versions of tkstep, removing one of these
 packages (4.2 or 8.0) disables the other as well, I filed bug reports
 against both of them.

 The interaction between the development packages should be considered as
 well (e.g. if both may be installed at the same time).

 Maintainers of tk and tkstep should discuss the problem and find a

 Thank you,


Reply to: