Hi Andrew,

Some good points...

> It might work with other images, but it might not.
> It might work with future releases of developer Squeak, but it might not.
>
> It solves the specific problem of - "FreeType Plus won't load into 
> sq3.10-7159dev08.04.1
> because MC1.5 doesn't run postscripts, initializes classes in a 
> different order, and fails to load FFI" .
>
MC1.5 does now run postscripts (it should have always run postscripts)

> I anticipate that that problem will be solved with future versions of 
> MC1.5 and/or FFI and/or FreeType Plus, at which point my script will 
> only be of historical interest.
agreed.

> I think something is missing here.
> How can the appropriate installer be found for a specific version, of 
> a particular fork/distribution, that is itself based upon some core 
> Squeak image?
> e.g.  sq3.10-7159dev08.04.1 is based upon  sq3.10-7159 .
> There are multiple version identifiers here...
>    distributionName=DeveloperSqueak
>    distributionVersion=08.04.01
>    coreImageName=Squeak
>    coreImageVersion=3.10
>    coreImageBuild=7159
>    coreImageReleaseStatus=beta

Which means to me that this is getting impossible, so we need to switch 
tactics. Perhaps it is time to start thinking about image "capabilities".

Plan A.

Let's note, if sq3.10-7159dev08.04.1 is based upon  sq3.10-7159, and is 
an assembly of packages, then it is simply a collection of packages with 
dependencies, and our package simply keeps up the tradition. If it 
doesn't have what it needs the dependency system takes care of that.

Plan B - Basic Capabilities

Each package nominates a "provides list". Normally a package provides 
"itself", however it can provide any "capability". So for example "Magma 
server" and "Magma client" both provide "Magma", an abstract capability. 
Packages that need "Magma" capability put "Magma" in their dependsOn: 
list and will not load unless "Magma" is provided. Which provider of 
"Magma" is left to the installers choice.

Plan C - Detailed Capabilities

We are using Sake as a basis for this whole system so we are not just 
limited to depending upon Sake/Packages tasks. We can specify 
dependencies upon the existence of a particular Class, Package, File or 
Method.

task dependsOn: { (SakeTask class: 'UUniverse') exists }.
> In the future, as the core image shrinks, I can imagine someone 
> creating a distribution based on another distribution based on some 
> fork and so on.
> So there would be a chain of version identifiers, e.g. ...
>
>    MyApplication.2.0.1alpha <- SpecialFork.1.0beta <- 
> DeveloperSqueak08.04.01 <- sq3.10-7159
>
> If this version chain was embedded in each image, could Installer use 
> it to find the most appropriate install script for each package?
Installer can. Its search path is fully configurable and is currently 
set to....

1. installer.pbwiki.com/ Page - Smalltalk version - author initials
2. installer.pbwiki.com/ Page - Smalltalk version
3. installer.pbwiki.com/ Page - SystemVersion current majorMinorVersion

Sake/Packages

The code "Packages current", is currently set to major-minor version. 
However I have changed it to try the following options:

'Packages' , SystemVersion current version asLegalSelector capitalized
'Packages' , SystemVersion current majorMinorVersion asLegalSelector 
capitalized
>> and we copy the definition of 'FreeType Plus' to 
>> PackagesSqueak39beta, and PackagesSqueak310beta but we change the 
>> load script to load whatever is the latest from squeaksource, rather 
>> than the package on SqueakMap.
>
> That's a bit dangerous.
> The latest on SqueakSource will almost certainly be full of bugs, and 
> might contain experimental code that does outrageous things.
> Like deleting all the font files from your disk, and installing a new 
> set from DodgyFreeFonts.org  .
> It doesn't, but you get my point :)
That is precisely the point...

Packages beta load: 'FreeTypePlus'.

Is specifically requesting the most recent and hence most dangerous 
version whatever it may be, (because I cant be bothered to go and look 
for it myself).

This provides package authors the easiest way of getting others on board 
with testing where they are at. The package author can say "Try the beta 
and see if it fixes your problem." The author is saved from having to 
update the "working" definitions until he his ready.

cheers

Keith










> Cheers,
> Andy
>
>
>