>  > The approach we plan to take is to create an AT 8.5 that has a
>  > pre-seeded teapot repository of extra modules (not all that were in 8.4,
>  > but a good selection).  These will install into the same place as if you
>  > were to use teacup.
>  >
>  > At install time, if no existing repository is found, we just copy over
>  > the pre-seeded repository (nice, fast and simple).
>  >
>  > If a repository is found at install time, we would need to ask the user:
>  >
>  > a. Use installing distribution repo (blow away pre-existing)
>  > b. Use pre-existing repo (don't update with distro repo)
>  > c. Merge
>  >
>  > Option (c) is nice, but it is slow, because it would mean doing several
>  > teacup operations to ensure the integrity of the local teapot db index.
>  >
> 
>  Would option b involve just installing ActiveTcl "lite" similar to
>  what we get today, and the new install would not see anything until
>  the admin did a teacup install?
> 
>  My thinking is this - if the new Tcl sees the old repository full of
>  extensions, things might not play well together.

What makes you think that ?

Maybe I should clarify something here. Namely about the 'existing
repository'. As the newest distributions all install the repository under
INSTALLDIR/lib/teapot and existing repository is found if and only if the
chosen INSTALLDIR is the directory of an existing ActiveTcl installation.
This can be an older 8.5 or 8.4. In both cases any packages in that
repository should be no problem at all for the new ActiveTcl.

If you install the fatter AT into its own directory then there is no
existing repository, at least none recognized, and the pre-seeded repository
is used without the user being asked anything. Because in that case there is
no conflict to resolve.


Option b now means that the pre-seeded repository in the distribution to be
installed is skipped and the existing repository is untouched. Linking the
new tclsh to use the packages in the exisitng repository is still done, as
it is exactly in the place where a repository is expected anyway.

Option b essentially tells the installer that the user is managing the
existing repository just fine and it should share with the new installation.

Option b is the default.


>  In fact, thinking along this line, a) makes me uneasy as well.  But
>  obviously there are a variety of use cases for various things.

Option a makes IMHO only sense if the existing repository is empty, i.e. not
managed by the user so far. In that case using (a) is the same as (c), but
much faster, as we can simply copy files around instead of having to
retrieve and install package by package.

>  In my mind, the most common use cases I can think of are:

>  1. install ActiveTcl lite - with few add-on extensions
>  2. install ActiveTcl medium flavor - a representative group of extensions
>  3. install ActiveTcl full flavor - teacup update equivalent

I think what we currently have is either (1) or (2), depending on if you
think our selection of packages in the pre-seeded repository is
representative or not.

>  > I just wanted to throw this out for others to ponder on.  If you have
>  > any ideas or questions, please let us know.  We want to finalize this to
>  > try and get a release out next week.

>  I do a teacup update-self;teacup update as soon as I install a new
>  version. My biggest need is to do the above on a machine, then to
>  create some sort of "snapshot" that could then be deployed across the
>  enterprise without users or admins having to do any sort of
>  interaction with an installer - just dropping a folder onto a machine,
>  or perhaps pointing to a common directory/folder and everything
>  working.

>  This latter is particularly important to me since at home, I'm still
>  hamstrung with a 48k ppp connection - as wonderful as teacup is, big
>  updates are tough to do at that speed...

With the fatter AT you can do this kind of thing, except for the 'without
using an installer'.

(1) Get the fat AT (after release)
(2) Unpack and install in some directory FOO.
(3) Update the installation, or install the packages you need/want.
(4) Replace the payload/lib/teapot directory in the distribution with the
lib/teapot in your installation.
(5) Repack the distribution.

Now the repackaged distribution contains the packages you have chosen in its
pre-seeded repository and
get installed by copying instead of teacup.

The user however still has to run the installer of this new distribution.
That hasn't changed.

The problem with getting rid of the installer is the binary patching needed
to insert the proper paths into the shells and libtcl/libtk.

--
        Andreas Kupries <andreask@[...].com> 
        Developer @ http://www.ActiveState.com
        Tel: +1 778-786-1122

_______________________________________________
ActiveTcl-Dev mailing list
ActiveTcl-Dev@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs