[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
|