Re: tk vs tkstep
David Engel wrote:
> On Mon, Jan 04, 1999 at 10:32:33AM +0100, Ulf Jaenicke-Roessler wrote:
>
> > 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.
>
> How does it complain.
Setting up automatic selection of wish.
Checking available versions of wish, updating links in /etc/alternatives ...
(You may modify the symlinks there yourself if desired - see `man ln'.)
Updating wish (/usr/bin/wish) to point to /usr/bin/wishstep8.0.
Leaving wish.1 (/usr/man/man1/wish.1.gz) pointing to /usr/man/man1/wishstep8.0.1.gz.
warning: /usr/man/man1/wish8.0.1.gz is supposed to be a slave symlink to
/etc/alternatives/wish8.0.1, or nonexistent; however, readlink failed: Invalid argument
Leaving wish8.0.1 (/usr/man/man1/wish8.0.1.gz) pointing to /usr/man/man1/wishstep8.0.1.gz.
warning: /usr/bin/wish8.0 is supposed to be a slave symlink to
/etc/alternatives/wish8.0, or nonexistent; however, readlink failed: Invalid argument
Leaving wish8.0 (/usr/bin/wish8.0) pointing to /usr/bin/wishstep8.0.
(Sorry for the long lines.)
I thought, this was well known, but it only occurs if tk8.0 is installed
after tkstep8.0 (eg when updating), because tk8.0's binaries overwrite
tkstep8.0's links, which are required by update-alternatives. The other way
around, when tkstep8.0's links overwrite tk8.0's binaries, there's no such
warning, although tk's binaries are gone!
(I don't understand yet, why dpkg doesn't complain about overwriting. This
looks like a dpkg bug.)
Compare tkstep4.2.postinst and tkstep8.0.postinst about the installation
of alternatives.
> > If the behaviour of tkstep8.0 is correct, it should conflict with and
> > replace tk8.0.
>
> I don't know of any reason why tkstep8.0 should conflict with tk8.0.
Well, this was only a suggestion, because both packages mutually overwrite
wish8.0 and wish8.0.1. And I think, that they provide basically the same
functionality. Or am I wrong here? Maybe there should be a virtual package
tk (which would be provided by tkstep), as there is tk-dev as well provided
by tkstep-dev.
Next problem is with the creation of packages. As I told before, I have
installed tk4.2, tk4.2-dev and tkstep4.2 (and similar 8.0 binaries). I
compiled a package with tk support, but it depends on tkstep, because
dpkg-deb finds the tkstep library before the tk library (an "official"
package, which suffers from this problem too, is awe-midi - I filed a bug
report because of a wrong dependency, but I understood the actual reason a
bit later).
See the next paragraph for another reason.
If you have another solution it will be fine for me (eg, reorganizing the
use of alternatives).
> > 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
>
> If you don't want this behavior, you should remove /usr/lib/tkstep from
> /etc/ld.so.conf.
It's not documented for tk or tkstep that I have to do this (or did I miss
it?). Nevertheless, I think it wouldn't be a good solution, to always have
to add or remove this line if the behaviour should be changed. I thought,
that alternatives were created just for this purpose. But I agree, that
it's not a good idea to use alternatives with libraries. Again, another
solution is fine with me.
> > 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.
>
> IMO, alternatives should not be used for libraries.
Yes, and I didn't have a good "feeling" when writing this. But it was only
another suggestion.
> /etc/ld.so.conf already provides a Linux standard way of handling these
> issues.
I don't know enough about ld and/or tk/tkstep to make a better suggestion.
Ulf
Reply to: