Note: Draft definition happens mainly on the team development mailing list and on the IRC OFTC channel #debian-tcltk

Changes to policy draft

You need committing privileges in the svn pkg-tcktk repository, where a specific policy directory exists. Non trivial changes should be discussed before commiting. It is also preferable doing one logical change per commit and commenting appropriately. Note that Tcl/Tk policy is versioned in major.minor.patchlevel style where patchlevel means typos or layout fixing and any other non-semantic changes. A snapshot of the policy document is always included in the tcltk-defaults source package.

Comments about current policy draft

[Please, maintain order and sign your comments]

About auto_load paths

See reference

FrancescoLovergine: The reason to move modules stuff under a subdir of /usr/lib is removing not needed traversing of hundreds of dirs, as currently, which impose a big performance impact for every package require instruction. Current proposal of core+packages+site paths and a tcltk subdir is based on Perl policy and partially approaches used currently by other distros (fedora and suse). Site dirs would allow admins to install/override their own packages as an alternative to environment variables. Architecture independent stuff should be moved under /usr/share (and notably both suse and fedora use /usr/share/tclX.Y for $tcl_library). Note that core packages have only arch-indep modules. Policy has to warn about changes in default -dev paths for non packaged extensions built by users, due to changes in default TEA scripts.

Michael Schlenker: I'm not sure if the packaging guide should mention the nuts and bolts behind auto_path and how it is initialized, but if thats of interest i could lookup the appropriate references in the Tcl docs / wiki and provide links, might make some good appendix references.

FrancescoLovergine: Done.

Michael Schlenker: If debian wanted to provide some extra features, it could override the standard Tcl pkgUnknown proc with its own version (via patching init.tcl), which could in principle print a meaningful error message for missing packages (if a list of all tcl extension/modules could be retrieved from apt at a reasonable time that message could include the correct deb module name) that are available instead of 'just' failing with a package not found.

FrancescoLovergine: I would avoid to add to core packages those kinds of Debian specific behaviors. They should be considered for additional packages that the interested administrators could install at their on will.

About default Tcl/Tk

See reference

FrancescoLovergine: It has been proposed to introduce true default tcl/tk/tcl-dev/tk-dev/tcl-doc packages which depend on a specific versioned tclX.Y/tkX.Y/tclX.Y-dev/tkX.Y-dev packages. This is the same approach used by ruby. Those packages should use alternatives mechanism to provide a series of binaries and files. This would allow to avoid source changes to version independent modules when a new default is introduced or a version is dropped and to do binNMUs for version independent extensions (note that Tcl/Tk APIs are always backward compatible). Version depedent modules could always use strict or relaxed (with >=, <=, etc.) versioning. The whole mechanism could be introduced gradually without breaking things. Using alternatives is mandatory to not break current installations that use the same mechanism. That implies anyway that default version could be changed by admin, independently by the official one. Could it introduce inconsistencies? The default tcl-doc should contain a valid snapshot of Tcl/Tk Policy, like other languages already do.

Michael Schlenker: It would be good if not only the shell #! style would be hinted at, but also add a recommendation that the script should specify its prerequisites also on the Tcl level by using something like this somewhere close to the top:

package require ?-exact? Tcl X.Y.Z                                                                                                             
package present ...                                                                                                                                                                                                                                                                          

A similar hint would be appropriate especially for typical wish scripts which are only very rarely really dependent on wish. Most of those scripts would also run when a simple

 package require Tk                                                                                                                                                                                                                                                                 

would have been added to the top and they are run with tclsh (at least from 8.3 onwards IIRC...) (the main different is on MS Windows where wish does not have std channels due to M$ broken APIs... and on X11 when using Xlib command line options to set X options.).

FrancescoLovergine: This is probably something useful for a specific Maintainer's Checklist Appendix in the policy.

FrancescoLovergine: Modules and extensions should be ideally able to be used with any current default version. Extensions need to depend on a specific version (or better declare a >=X.Y relationship) only if they require a specific API level or a later one (for instance object-based interface is available only with 8.0+, stub library is available only in 8.2+ etc). Tcl/Tk APIs are backward compatible and very stable, so there is not need to build extensions for all Tcl/Tk versions available, but it makes sense building against the minimally compatible version or a later one, and that could be specified with a version relationship in default -dev package build-dependency. The same can be done for modules and dependency on tcl and tk default packages.