<goran.hultgren at bluefish.se> said:
>You just said "if available" which sounds optional to me! :-)
>
The optionality refers to the availability of tests, not to running them if
available.

>Well, it feels a bit weird to me. If I want to produce a minimal image
>those tests are - no matter how nice and secure they make me feel -
>simply baggage during deployment/runtime.
>
Remove all subclasses of TestCase and all classes starting with Mock... and
you're a long way. Other resources may be included in a manifest file in the
SAR so an image stripper can find them.

>Actually, even though most packagesystems do include the dependencies
>inside the package we (especially Daniel and I) are opting for
>externalizing this as a "package configuration" which there may be
>several for a given package release. 

That means that you unify the package distribution and package contents
method. E.g. when I obtain a package outside SM, the package wouldn't have a
way to verify whether the environment it lands in is the correct one
(important for off-line situations). Therefore, I think you need the
dependency information in both places, so that the package can check its own
environment once it starts installing into the image - independent of how it
arrived there. 

It's probably similar to the double validation you often end up doing in the
user interface and the business model: the UI validation is there to help the
user, and the business model validation is there to keep the business model
correct. SM dependencies would be helping the user, while package-internal
independencies are necessary to keep the image consistent.

>"Spaghetti tracer 1.0 has been verified by Daniel Vainsencher to work
>with prerequisites DVS
>1.34 and Connectors 1.3 on top of base image 3.2."
>
Are you planning to have multiple such 'statements' on packages? Like:
"Spaghetti tracer 1.0 has been verified by Cees to work with DVS 1.35 ..."
" ... by Goran to work with DVS 1.34 and Connectors 1.45 .."
etcetera?

>(this last part is
>interesting. I haven't decided but it seems to me that base images could
>be considered as some kind of package. They have releases, they can be
>downloaded, you can depend on them etc. This would in that case unify
>this last step with step 2)
>
CPAN treats the Perl distribution as just another package. It's annoying
sometimes, because it happens that you download a package with Perl 5.x, and
the package has a prereq on Perl 5.y (y > x); CPAN reacts by downloading,
configuring, and installing the new Perl distribution. I don't know whether
that is the useful behavior (probably better to say "you can't do that on
Squeak 3.1").

>4. When a new configuration is discovered or when a dependency needs to
>be added we don't need to release a new version of the package itself.
>
That is an advantage, of course. It's also all a matter of trust: if the
author inside the package states 'A' on dependencies and tested platforms, and
two people on SM state 'B' and 'C', who do you trust? How do you automate this
(when fetching chains of dependencies)?

>Anyway, my main point here is that I actually think a package should be
>minimal in this respect and having the package configuration as a
>separate entity gives us more flexibility but at the same time it is
>quite simple to understand.
>
With, IMHO, the explicit trade-off that, given the likelyhood that SM
will in due time be too large to download, off-line configuration is
not possible anymore.  Plus the assorted trust issues to be resolved...

(I'm ok with the trade-off, just as long as the decision is made consciously
;-))

-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo