[Pkg-tcltk-devel] Bug#516178: please provide an 8.5 version of tcl and tk metapackage

Francesco P. Lovergine frankie at debian.org
Wed Feb 17 19:35:11 UTC 2010


On Tue, Feb 16, 2010 at 07:43:49PM -0600, Jonathan Nieder wrote:
> Hi,
> 
> Francesco P. Lovergine wrote:
> 
> > Those issues will be solved during squeeze release
> > anyway when tcl/tk will move to 8.5 default.
> 
> What can I do to help with this?
> 
> > On Fri, Feb 20, 2009 at 01:02:26AM +0800, darren wrote:
> 
> >> please provide an 8.5 version of tcl and tk metapackage.
> >> related bugs #503113 and #515325 in which user reported that
> >> gitk should depend on tk instead of tk8.5,
> [...]
> > The current Tcl/Tk policy is quite clear about that.
> > Packages should depend on 
> > 
> > tk (>= 8.5)
> > 
> > iff the minimal version is _required_. Having a working
> > but ugly interface does not justify a strict versioning
> > in this case. The aim of this approach is allowing to
> > migrate tk default version to 8.6 or what ever without
> > having to rebuild all rdepends to have something like
> > 
> > tk8.5 | tk8.6 | ...
> > 
> > for ever as in the past.
> 
> FWIW I think this policy is problematic.  In a package like gitk
> (which requires tk 8.4 or greater), it would be nice to depend on tk
> (>= 8.4), use wish, and be done with it.  But in the current
> situation, that is not really right, since the user might have both 
> current tk (which pulls in tk8.4) and tk8.3 installed and have chosen
> to use tk8.3 to provide wish.
> 
> With the current policy, what can a packager do?
> 
>  - Use wish-default instead of wish:  This would be reliable but
>    cheats the user out of new tk features.
> 
>  - Depend on wish and use wish:  That dependency would appear to be
>    satisfied by tk8.3, which is a no-go.
> 
>  - Breaks: tk8.3:  But gitk _doesn’t_ break tk8.3, and using this
>    strategy in general ruins the advantage of allowing some packages
>    to use one tk version and others to use another.
> 
> No, there are only two reasonable options for a packager I can see:
> 
>  - The old way (Depends: tk8.4 | tk8.5 | tk8.6 | ... and run $(which
>    wish8.6 wish8.5 wish8.4 | head -1)).  This does not let the user
>    choose a tk version, and it requires updating dependencies each
>    time a new tk version comes out.
> 
>  - Depends on tk (>= 8.4) and use wish.  By default, wish will point
>    to wish-default, which works.  The sysadmin might set wish to
>    point to wish8.3, in which case gitk will complain and the user can
>    put a symbolic link to the correct wish on his $PATH.  The sysadmin
>    might set wish to point to wish8.5 or wish8.6, in which case, all
>    the better.
> 
> This is ugly.  I’d rather have /usr/bin/wish be a wrapper script that
> runs the most recent wish version installed.  This is almost always
> what the user wants.  If a new tk version breaks old software, it can
> use Breaks: and then we should fix the bug!
> 
> Just my two cents,
> Jonathan

First of all 8.3 is going to be dropped. But for that, the possibility
of choosing the default version by admin is something that I personally
consider deprecated, still around since the old pre-policy days to be
friendly against users. The reasons against that are evident and you
listed some of them yourself.

Also packages and applications can declare the minimal compatible Tcl version
and not doing so is something that should be considered a package/app bug.

That said, using a wrapper is something that violates the rule of 
least surprise. I would simply remove the possibility for the admin
to choose the default Tcl/Tk version by config, which is coherent 
with other languages such as C/C++, Python or Ruby.

-- 
Francesco P. Lovergine





More information about the Pkg-tcltk-devel mailing list