Re: [Tclish-devel] Installer modules

[Steve C. <ste...@mq...>]

On Thursday 19 July 2001 19:05, Peter Farmer wrote:
>
>    - interface to the TEA build system

I'd rather see this the other way around: an interface from TEA to the 
installer.  I guess that what you mean here is that the installer can query 
the TEA config.status or tclConfig.sh to find useful bits of information. I 
have a script that does this as does your installer.  I think this would be 
most useful as part of a TEA support library which can be invoked to write a 
config file for the installer for a project.  



>    - de/compression utils

You mention a tcl only unzipper later, how feasable do you think this is? 
The mkZipLib extension is C but should be very portable and is quite small.  



>    - comprehensive filesystem abstraction layer ?
>      - especially determing available filespace,

Very good point, how doable is this. I imagine it would need a call to a 
system routine on Mac and Win, of course on Unix you can df. Is there another 
way on non unix platforms?

>        checking/setting access permissions,
we have [file stat...]

>        handling case-insensitive filesystems,
I guess you should be warned if your package contains names that might clash 
under some O/S. So some kind of package verifier would be needed.

>        handling mangled namespaces (like fat16)

Must we...;-(

>
>    - filesystem recursers/crawlers, file search
>    - file renaming (based patterns/regexps)

>    - system level "config repository" abstraction layer ?
>      (for Windows Registry/Ini files, Unix system config files etc)
>    - user level "config repository" abstraction layer ?
>      (Windows Registry, Unix ~/. files etc)

I'd be in favour of leaving this alone unless someone can come up with a good 
x-platform solution.  We can provide tools to make these things easier to set 
up and suggest standard recipes for x-platform installation.  

>    - config file parsing tools & geneartion tools
>      (maybe serialization tools that feed into a DOM driven update
> engine
>       and then xslt files to generate the updated native file ?)

See the comments above, I really think that the simpler this config file can 
be the better.  A simple tcl only extension consisting of one source file 
should have a package description file which is trivial to write and 
comprehend once written (if it's generated automatically).  Those used in 
tclish and your tclxml installer are just about right in my mind.


>    - internationalisation support - beyond just UTF 8 capability.
>    - some sort of key-variable management system that
>      is aware of relationships/dependencies between themselves
>      and propagates the changes through the dependancy chain.

I'm not sure I get these.


I'll cut this here and comment on the rest in another msg.

Steve