On Monday, August 4, 2003, at 01:36  PM, Lex Spoon wrote:

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

Quite true. But there are degrees of confidence you can have about 
stuff working. I suspect that Göran was taking about different degrees 
of confidence implied by the following two assertions:

(a) I tried PackageA 1.0 and PackageB 3.2  together and they worked for 
me.

(b) Package A 1.0 works with PackageB 3.2 and all versions after that.

There are two things that make me trust (a) more than (b). The first is 
that (a) tells me that somebody actually tried it out. It's not 
guaranteed to work for me, but that fact adds to my confidence more 
than theorizing, which is all you get with (b).

Second, (b) is time sensitive, where (a) is not. If at some future 
time, a new release of PackageB breaks compatibility with PackageA, (a) 
will be as true as it ever was, but (b) is now incorrect. So to 
evaluate my confidence in (b), I have to know when the assertion was 
made.

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

This question is the real reason for my post; I think Göran's proposal 
there was complicated and quite unnecessary.

Seaside is a good (semi-hypothetical) example - it requires a web 
server to be useful. Let's say it knows how to interface with PWS, 
Comanche and Wazoo, all of which have different interfaces. Avi only 
uses Comanche, so he posts configurations indicating what versions he's 
tested with. Other people can post their configurations as well. We end 
up with the following in configurations on SM:

Seaside 2.3, Comanche 5.0
Seaside 2.3, Comanche 5.1
Seaside 2.3, Comanche 5.1.1
Seaside 2.3, KomHttpServer 6.0, KomSeasideService 1.0
Seaside 2.3, Wazoo 1.1
Seaside 2.3, Wazoo 1.2

So if you're loading Seaside, it's easy for the dependency engine to 
suggest that you load a web server, without knowing that you need some 
formal "webserver" interface. In fact, Seaside is a good example here, 
because the web servers it works with don't provide a polymorphic 
webserver interface. Instead, Seaside nevertheless knows how to deal 
with them all on their own terms.

With the simple heuristic of preferring newer versions to older 
versions, SM can suggest that to run Seaside, you should also load one 
of:

Comanche 5.1.1
KomHttpServer 6.0 and KomSeasideService 1.0
Wazoo 1.2

> 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".

I think this can be handled in the same way. Along with "known good" 
configurations, we can publish "known broken" configurations. This 
would work whether the conflict is because two package try to provide 
the same thing and trample on each other in the process, or just 
because of a bug some where that prevents the combination of them from 
working right.

Here again, there has to be some way for specifying the relevant 
packages, so we don't end up with bogus incompatibilities.

Colin