Purpose: to discuss the reasons why one would not use a tclkit/starkit based solution?
On a different wiki page, where such a discussion would have been off topic, the question "I don't understand why more people don't use tclkit" came up.
Some of the reasons include:
LES: for my own personal use applications, I prefer to rely on ActiveTcl because it is batteries included - I don't have to worry about installing extensions (packages), they're all there already. Also, once I planned to write a commercial application and starkits offer no source protection whatsoever. I gave up on the idea - too much work and not enough time - but I'll bet many developers have a problem with that. Apart from that, yes, I have distributed a couple of applications as starpacks and it all worked just fine for that purpose since they were very simple (no packages needed) and not commercial.
LV: While starpacks have the appealing property of being a single file for distribution, it does limit one to generating versions for the tclkits available. Distributing via starkit at least allows people with locally built tclkits or variants to try to use the starkit. Alas, there's no guarantee that your application is going to work if you don't distribute either tested starpacks or versions of tclkit known to work with the application. This is due to the evolving nature of Tcl and Tk, as well as the decisions made during the building of variants as to whether all the functionality of the original tclkit will be provided.
RS prefers to do the simplest thing possible, and that usually is a single file script (deployed via CVS to colleagues). One advantage of this is for instance that one can compare versions with e.g. cvs diff, while I wouldn't know how to compare two starkits without unwrapping them..
LES Simples is good, Richard. But my friends and colleagues know nothing about Tcl. I couldn't just send them bare Tcl scripts. Most people know nothing about Tcl. Developers and end users really need the packaging solutions.