[Pkg-tcltk-devel] [RFC] Aspects of policy to be discussed

[Francesco P. Lovergine]

I tried to summarize the current de facto policy used for Tcl/Tk packages
and extensions (both core ones and not). There are some peculiarities of
Tcl/Tk which need for sure more clarifications and specializations
probably.

http://pkg-tcltk.alioth.debian.org/tcltk-policy.html/

A couple of comments:

Default Tcl/Tk
--------------
We have currently not a true default package as in the Ruby/Python 
cases. We traditionally distributed versioned Tcl 
and Tk with alternatives and left to the administrator the choice of 
a 'default' Tcl and Tk. This is questionable, because Tcl/Tk modules
(let me call packages as 'modules' starting from now to avoid
ambiguities) require to depend on a versioned Tcl/Tk like tcl8.4 or
tk8.4 (for version-dependent module) or depend on a (tclX.Y|tclsh) (tkX.Y|wish). 
In practice I think almost(?) no pkg uses the second strategy, so that we have 
tons of non-sense versioned dependencies in the archive at source level.
This can be or not a problem currently, but it will require changes to
many (even if version indepedent) source packages when 8.5 will be 
considered the new default version. Consider also that many extensions
could be used without rebuilding thanks to the stub library and this
increases the number of packages with a non-sense versioned dependency.

Therefore my own opinion is that we should introduce a tcl and a tk
default packages which depend on the current (versioned) default ones.
This would allow avoiding source changes and rebuildings for pure 
tcl/tk scripts which are compatible with all versions of tcl and tk.
It could be also considered a post-lenny goal. In the meantime
the new pseudo-packages could be introduced and a migration to
the new package started.

Auto_path
---------
The auto_path issue is the most critical IMHO. I found current status
largerly under-optimal for performances and not consistent with 
other scripting languages (and distributions too). My own proposal 
is summarized in the draft policy. This should be considered a Lenny goal 
and violating packages should be bugged and fixed before releasing.

See also comment by Donal K. Fellows on Tcl-Core:

http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/2542650


-- 
Francesco P. Lovergine