Hi,

My first suggestion is to create small application wrappers and put all
of the code in a library package. For example, I would create and
distribute the tclchecker as follows:

#!/bin/sh
# Begin tclchecker exec "/auto/<localpath> /TclDevKit/4.0.279191/bin/tdkbase" "$0" ${1+"$@"}
##
package require tclchecker
::tclchecker::main $argv
# End tclchecker

This way the application under "<root-path> /bin/tclchecker" never has to
be updated and all updates to tclchecker library can be obtained via
teapot as a package.

This still doesn't answer the question on how to update the core
tclsh/wish binaries. I guess these binaries would have to be downloaded
separately outside of teapot, or teapot would have to provide  a "teapot
update-self" equivalent for these binaries.

My second suggestion would be that the teapot should create/update
copies of the latest downloaded version under bin directory. This would
be similar to current ActiveTcl distribution where it contains tclsh84,
wish84 binaries as well as tclsh and wish binaries (where tclsh is a
copy of tclsh84).

Hemang.

Virden, Larry W. wrote:
>  Note that the problem isn't just an academic one, or a topic relevant
>  only for home-grown applications. The activestate repository has several
>  applications already within it. And, of course, the most important
>  application - tclsh - is probably going to need the issue resolved at
>  some point (say when the latest 8.5 compiles are available in the
>  repository).  
> 
>  Notice that teacup _would_ have been the first application ... Except
>  that, in the latest teacups, the problem was worked around by a
>  specialized built in update command.
> 
>  Perhaps rather than have
> 
>   teacup update-self
> 
>   once the issue is addressed, that special case will no longer be
>  needed.
> 
>  I've been thinking about this for a number of months, with no really
>  good solution. My initial thought was that an application should be
>  installed into the same directory as the tclsh, then later I thought
>  perhaps things should go into the same directory as teacup. Right now,
>  that latter choice is becoming more and more attractive to me. The
>  problem, of course, is when someone manages a repository containing code
>  for multiple platforms. Perhaps things should be installed like this:
> 
>  Path/to/bin/
>     Path/to/bin/binary-platform1/
>     Path/to/bin/binary-platform2/
>     tkcon_version1
>     tkcon_version2
>     other tcl scripts
> 
>  Then, if the administrator so desires, they can create short cuts to
>  specific versions of tkcon, for example...
> 
>    
_______________________________________________
TDK mailing list
TDK@[...].com
http://listserv.ActiveState.com/mailman/listinfo/tdk