hi goran

>
> There are IMHO two distinct problems we want to solve:
>
> 1. To be able to post a "load script" (earlier I called this an "image
> configuration" but that was maybe a tad too specific) that when
> installed installs numerous other package releases in a specified order
> into the image. This can be used for:
> 	1. Distros. A full mega image with whatever you like to distribute.
> 	2. Kernel building. The load script will then act as a Make file to
> load packages on top of the microkernel image from Dan and the boys.
> 	3. Tasks. A load script can easily install a whole bunch of stuff that
> someone thinks is a good "bunch of stuff" to have for a specific task.
> Like "Web Application Development" including Seaside, Comanche, SSP 
> etc.
>
> 2. To be able to describe the minimal requirements a package needs in
> order to function. I call this a "package configuration". Given a query
> of for example a set of packages we want to install, we can traverse
> these published package configurations and figure out what other 
> package
> releases we need to include and if there are conflicts etc.

Call it prerequisite ;)


>
> Ok, what is a "load script" then? Well, as some of you have already
> described it is simply a .st file that uses the SM API to load
> packages/package releases into the image. Having it as a script gives 
> us
> full flexibility - we can install a package release, patch it up, fix
> some nuisance, load the next etc. It also makes a "load script" nothing
> else than a package.
>
> But currently SM can only load packages and not specific package
> releases. That is why we need to add support for that. When we have 
> that
> we can probably write:
>
> SMSqueakMap default installPackageNamed: 'SSP' version: '1.0'
>
> ...or something similar. If we follow the convention that a package
> release is immutable (we can't really promise that today since the
> actual packages aren't stored at SM) this would let us create
> "immutable" load scripts too. If it only loads specific package 
> releases
> in a specific order then the end result will always be the same.
>
> Now - a load script can also do dynamic stuff like for example load the
> newest available package or ask the user for more direction etc. So, we
> would probably like to distinguish between a "dynamic load script" and 
> a
> "static load script" or something like that. Still, just a category on
> SM so the "load script" maintainer gives us his word.
>
> Ok, so a load script is nothing more than a .st package with a few more
> categories on it. Neat! The only thing missing from doing this today is
> the unability to specify a specific package release. But otherwise this
> is doable today - and I have already added categories for this!
>
>
> Fine, what the heck is a package configuration then? It is a tested
> minimal setup for a specific package release to work. So it goes
> something like this in english:
>
> "I Gˆran Hultgren have verified to my abilities that package release
> Mungo 1.3 works fine with minimal required package releases Bimbo 2.4
> and Zingo 1.02."
>
> Notes:
> 1. A package configuration is not a script. It is declarative. 
> Otherwise
> we can not use them for dependency analysis and conflict detection etc.
> 2. For a given package release (Mungo 1.3) there can be numerous 
> package
> configurations by different people - the maintainer of Mungo but also
> from dope heads like Gˆran Hultgren.
> 3. A package configuration is published by a person. You can choose to
> trust him/her or not. Or you can choose to only trust the maintainer of
> Mungo and thus ignore package configurations from other people.
> 4. A package configuration is a tested setup for one specific package
> release. The above does not say if Zingo works ok, only that Mungo 
> works
> according to Gˆran.
> 5. A package configuration *only* lists package releases, not packages.
> That is after all exactly what Gˆran tested - he can not make any
> promises for using Mungo 1.3 with Zingo 2.0.
>
>
> Ok, given these package configurations we can traverse them and figure
> out what other package releases are needed and if this presents us with
> conflicts. And there will be conflicts! Since we yet typically can not
> have Zingo 2.0 at the same time as Zingo 1.02 we will want to deal with
> the conflicts. How? Well, if we add one more little thing this can
> actually be helped a lot:
>
> For each package release we let the maintainer categorize the new
> release in respect to how much it has changed relative to the previous
> release. I call this the "compatibility level" of a package release.
> Given 6 levels (or more/less, I will not describe them in detail here)
> we can then give the user advice like:
>
> "Hey, Mungo 1.3 has a dependency conflict with Pingu 1.2. They both 
> rely
> on Zingo but Pingu has only been verified to work with Zingo 2.0.
> According to the compatibility level of Zingo 2.0 it is categorized as
> *compatible* (=level 4, changes have been made but the maintainer says
> he hasn't changed the API so it should work), would you like to use 
> that
> instead?"
>
> And then the user can say, hey - hit me. It could also have said that,
>
> "Hey, Houston. We have a problem. Mungo 1.3 has a dependency conflict
> with Pingu 1.2. They both rely on Zingo but Pingu has only been 
> verified
> to work with Zingo 2.0. Zingo 2.0 is categorized as *non compatble*
> (=level 6, the maintainer promises us that there is no chance in hell
> that it is compatible, the API is totally new) so we are basically up
> shit creek. Go have some coffee?"
>
> Ok, this turned into a long post. Note also that the two concepts
> outlined above have a nice property - since a "load script" is a 
> package
> it will be versionable. No strange things there.
>
> And since a "package configuration" only refers to package releases
> (which are immutable) they do not need to be versioned I think - it
> there was something wrong with it, just change it.
> And a "package configuration" is not a package because they differ in a
> few important ways:
>
> 1. They are not installable code. They do not refer to something
> downloadable etc.
> 2. They are connected to a specific package release. That is not
> something a package is.
>
> etc. So this is a new beast. But load scripts are not.
>
> Anyway, how does it sound?
>
> Daniel has been bugging me with trying to unify these two concepts but 
> I
> like them separated and simple. Note that a "load script" can of course
> use the package configurations through the API of SM. Note also that a
> load script can of course use other load scripts - they are after all
> just packages. In that respect only our imagination sets the limits.
>
> Note also that a package configuration is not "composable" or anything 
> -
> it's a simple list (possibly ordered) of package releases, nothing 
> else.
> Maybe we could let it have a Composite pattern and let it refer to 
> other
> package configurations - but perhaps it will just make things
> complicated.
>
> regards, Gˆran
>
>
>
Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes