tk vs tkstep
Hi,
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
solution.
Thank you,
Ulf
Reply to: