[SM]Plan...

Stephan Rudlof sr at evolgo.de
Tue Aug 3 22:58:12 UTC 2004


Göran and all,

goran.krampe at bluefish.se wrote:
> ...

> Now - how does the current dependency plan look? Well, Stephan and I are
> exchanging thoughts and it looks "approximately" like this:
> 
> - We both rely on the maintainers to enter "compatibility level"
> information when registering new releases on SM. My model would have
> been a single drop down menu selection. Stephan's richer model would
> mean a multi select list with circa 6 items in it. So both are easy
> enough and we will probably go for a unified variant.

I think for my model the drop down menu selection would suffice to! See
Swiki page about 'compatibility codes':
  http://minnow.cc.gatech.edu/squeak/3792
, and especially the questions to the package maintainers to be
answered: one of them answered with 'yes' should be sufficient.

Note: The page doesn't comprise all aspects, which it should comprise,
so far, but I'm interested in *all* kinds of feedback (especially if it
is understandable already) yet.

> 
> - I am focusing on "configurations" and "anti-configurations" and a
> dependency engine based on those.
> 
> - Stephan adds a few other concepts to the model, especially his Caps
> and Transformations.

For me it makes sense to use the "configurations" and especially the
"anti-configurations", too: they are valuable informations given by the
users usable for *every* dependency resolving system.

> 
> To us it currently seems like we can experiment with both these models
> in conjunction and

Agreed.

> I will make sure SM supports Stephan and his needs to
> try his additions

Thanks.
I highly appreciate the discussions with Göran about this complex domain
happening in a very constructive athmosphere! (Though they have led to
the longest mails I've ever written...)

> - when his design has stabilized.

Which will take a while ;-)
For me the concept of the 'compatibility codes' already has stabilized,
and I have tried to explain it from a praxis POV in the mentioned Swiki
page; so that can be treated as 'state of the art'.
But while thinking about the dependency resolving mechanism some new
aspects have appeared (especially the difference between pre- and
post-requirements), which enriches the needed algorithms ;-)

Note: With pre-requirements I mean preconditions to be fulfilled
*before* e.g. installing one package version, whereas post-requirements
have to be fulfilled at the *end* of the *whole* installation process of
all package versions to be installed, to get a working system. This
makes a *big* difference. Both sets are requirements for a working
package, though, and in addition these sets often won't be disjunct.


Greetings
Stephan

> ...



More information about the Squeak-dev mailing list