I am still confused.  Thanks for your patience!  I am used to a simpler
model (I tihnk) where you simple have name-based dependencies plus
optional version number dependencies.  Package authors simply declare
their dependencies in the packages.  This approach is tried and true,
and I think anyone will understand it.  The approach you are describing
may well be better, but I'm having a hard time seeing how it works.


Before getting into it, let me toss out a little axiom of software
development:

> > This is not true for those who have tried it.  Normally you don't use a
> > version dependency at all.  Even when you do, you usually say simply
> > "version >= 3.2".  It's not hard in practice.
> 
> Again - I think such a dependency is strange. Nobody can make such
> promises.

There are no guarantees when it comes to software correctness.  Let us
remember this when we discuss the "promisses" that are made in package
dependencies.  Even if you test with a specific set of installed
versions, there is no guarantee that the package will work on someone
else's machine.  This axiom is so ingrained in me that when anyone
defies it, it doesn't sound like meaningful speech to me.



Okay.  On to the questions.

First, what is a compatibility level and where does it come from, ie who
declares it?  FWIW, there are only two styles of compabitily that seem
to come up in practice; I can think of no exceptions:

	1. There is no compatibility.  The package is under intense
development.

	2. There is upwards compatibility within major versions.  If your code
works with 3.5, then it will work with 3.6, 3.7, etc.  No guarantees for
4.3 however.

I wonder if a checkbox would suffice?


Second, how do you know which packages to mention in a tested
configuration?  Surely there is a list somewhere in the package's
meta-info about what packages are relevant.  You aren't going to include
every package the image includes, surely.


Third, what do you plan to do with tested configurations?  In
particular, what happens if some people use only the newest libraries
and some do not?  Then the server ends up with this pile of
configurations that users have to select among.  Are you certain that
you cannot get in the situation where one package is only tested with
RePlugin 3.5 and another is only tested with RePlugin 3.6?  What do you
do in this case?


Fourth, can you try again to explain how you'd have an abstract
webserver interface, or an abstract smtp-client interface?  The simple
model I am familiar with allows packages to include declarations for
abstract interfaces that they provide.  Thus, Celeste can declare
"Provides mail-sending-client", and packages which depend on
mail-sending-client can grab Celeste if they want it.  It's extremely
simple.


You mention the worry that one package's mail-sending-client might be
different from another, but that is just as much of a bug no matter how
the mail-sending-client API is documented.  Including a concrete package
named mail-sending-client does not get around the fact that one or the
other package might have a buggy or inconsistent implementation.  This
gets back to the axiom of no warranty I mentioned to begin with.



> What I truly meant above is that it gets much harder to analyze. My
> model will (Something I believe after making scenarios and playing
> around with lots of arrows and circles :-) hopefully fit pretty nicely
> with an engine that can - given a list of needed packages or package
> releases - compute what I need to install. I still stand by the fact
> that having a model with boolean algebra and operators makes it much
> more complex.

Maybe it's more complex (I have no idea), but it's proven to work just
fine in practice, so it is not so complex that it cannot be implemented.
 Also, remember that in practice almost all the requirements are either
empty, or are of the form "version >= x".



> Given SM1.1 we will have the ability to build the dependency engine as a
> separate tool. This is because I want SM to be targeted and tight - I
> don't want it to "handle evertyhing" and when I realized that it should
> only deal with maintaining a distributed model of package
> metainformation then I also realized that a dependency model + engine is
> just a client of on top of that model.
> 
> SqueakMap is just the map.
> 

Well, I would hope that in the future the standard SqueakMap client does
in fact handle dependencies correctly.  Also, I hope it is possible to
download all the package metainfo in batch, so that the standard client
can do smart things.  But anyway, this is all just moving the dirt
around.  Everyone wants dependencies, and there is a question of what
they should look like.


Okay, let me toss out one more query, to add to the one about abstract
packages.  Do you have any ideas about *conflicting* packages?  For
example, you may only be able to load one top-level GUI package
(SCMorphic or MorphicWrappers) at a time.  Or, a new package may be the
union of two older packages, and thus you can't load the newer package
while either of the older ones is loaded.  With dependencies, you can
add other kinds of dependencies, in this case "Conflicts with foo and
bar".

(Yes, the algorithm grows more complex, but again, it only has to be
implemented once, and it has been implemented in other contexts.)



Cheers,

Lex