[Squeakfoundation]Re: Basic tenets of what goes in the image

[goran.hultgren@bluefish.se]

Doug Way <dway@riskmetrics.com> wrote:
> 
> goran.hultgren@bluefish.se wrote:
> > 
> > Daniel Vainsencher <danielv@netvision.net.il> wrote:
> > > This is my proposed base policy on what should go into the image
> > 
> > ...
> > So please, stop thinking in terms of "the base image"! Flow? It should
> > IMHO not go into the base image. In fact IMHO Networking should rather
> > be *cut out* of the image into a package. Much like Tim said in another
> > reply.
> > 
> > ...
> > I strongly urge everyone to keep the focus on *packages* and not the
> > base image. This also applies to the discussion about 3.4alpha going
> > into beta and the discussion about putting SM into the base image, btw.
> > 
> > If people still want to talk about a "base" of some kind then by all
> > means we should create one! How? By selecting packages that we want to
> > consider to be the base packages.
> 
> I was just thinking that perhaps we need a term for what we've been calling the "base image", even though it will eventually be composed of packages.  (I think Daniel was probably referring to this new thing, not the old image.)

Ah, ok. :-) Didn't get that.

> Should it be called the "base release"?  Or perhaps the "base configuration"?  (I guess that one would have to wait until we have support for package configurations.)

Actually we can already today do what I call "load scripts". Perhaps I
need to publish one to show how it is done. It is essentially a .st.gz
file that uses the SqueakMap API to install packages. Yes, we don't have
SMPackageRelease yet - but you can either install "the latest known".

When we get SMPackageRelease then we will be able to make these "load
scripts". They can be used to build images and thus can be considered to
be "distros" or whatever. Again - this is STTCPW and even thought they
are not declarative they can instead do "smart things" like asking the
user what he/she wants! In that case it should be called a "dynamic load
script" (see category "Package type") since it doesn't necessarily
produce the exact same result each time. The other is "static load
script".

Sidenote:

I am leaning over to Daniels general design idea that if SM has
"packages" in a more general sense (and package releases) then we can
handle what Daniel and I have been calling "configurations" as simply
another kind of package. Now - my last design in my head lets SM handle
three basic things: SMPackage (with SMPackageRelease), SMResource and
SMPerson.

In such a future SM a package would be typically installable code and
SMResource would catch much everything else. The line is a bit blurry
for some things, but the main difference is that SMPackage has releases
(versions) and SMResource doesn't.

Blabla, I will type all this down this today... :-)

> We still want to have this concept of a "base release", which will be the thing that we release as Squeak 3.4, 3.5, 4.0, etc., even though it will be composed of packages.  Of course, this release won't necessarily be the totally dominant form of Squeak that has been used by everyone in the past... other people/organizations may come up with competing releases/configurations, too, since it will now be much easier to do so.

Right. The technical name for such a distro on SM would probably be a
"load script". At least until we have more advanced concepts of creating
coherent package configurations - I am actually not building that into
SM - the idea being that hey, it's just a new kind of resource/package
which you can put up there. (I know my thoughts are hard to follow)

> But there will still be some value in having our group (The Guides) put out a release on a regular basis, as a sort of standard... the thing that will appear on squeak.org for people to download.

Exactly.

> So what should we call this thing? :-)

Well. :-) Technically one way of doing this would IMHO (and for
starters) consist of:

1. A kernel image. (I am thinking of posting these as an SMResource on
SM)
2. A load script. (Since a load script is a package it can actually have
releases)

So... being concrete, we create a kernel image - in the beginning that
is essentially what we already have. We name it something and put it on
SM as an SMResource named for example: "Guide kernel image 3.5". Note
that version is included in name since a resource doesn't have releases.

Then we post a package of "Package type" "Static load script" (or
dynamic, I don't know). That package is a simple .st.gz file that uses
the SqueakMap API to install specific package releases in a specific
order. It could even do tricks along the way since it is after all a
script - that is a good flexibility to have I think. We name the package
"Guide distribution build script" (or something) and set the version of
the specific package release to (to keep in synch) "3.5". Something like
that.

We could also post a "prebuilt" image like a resource named "Guide
distribution prebuilt image 3.5".

And if you want to build it yourself you simply download the "Guide
kernel image 3.5", fire it up, install version 3.5 of package "Guide
distribution bild script" and off it goes loading all the other packages
on top.


Ok, so given all this. Names like "distribution" or "build script" pops
up. Perhaps there are other names for the "distribution" thing. The name
"load script" or "build script" does on the other hand sound like
exactly what they are so they are pretty good IMHO.

> And we have talked about a minimal release versus a larger "kitchen-sink" release (similar in content to the current base image)... I guess we will have to come up with names for both.
> 
> - Doug

Well, see above.

regards, Göran