cg at cdegroot.com wrote:
> Colin Putney <squeak-dev at lists.squeakfoundation.org> said:
> >A slight variation on this, which I think would work even better, would 
> >be to make "requires" refer to an update number rather than a release. 
> >So you'd get 'base-5968'.
> >
> So how would you express, in this case, an incompatible release?
> 'base-5968' could only mean 'update 5968 from base stream or newer'.
> 'base-3' means 'anything tagged with major release 3 but not newer'. 
> 
> (of course, step two is to add operators: 'exact', 'at least', 'and',
> 'or', ...; so you could express 'major release 3 or major release 4 (but
> not 1, 2, 5, 6, ...)'; 'major release 4 or anything newer', 'major
> release 5 or older versions', etcetera; step three is to add
> stuff like 'suggested', 'conflicts' to the 'requires' bit).
>
> The good thing here is that responsibilities are clearly put where they
> belong: the author of a providing package has the responsibility to
> correctly tag functionality/interface compatibility; the author of a
> requiring package has the responsibility to correctly state the
> compatibility level required. The default - absence of requirements
> specification - would indicate that the package would use some defined
> subset (like ANSI Smalltalk) only. 
[SNIPPED description of Debian and analogy]

Btw, first of all - when building SM I was heavily influenced by Debian.
We use Debian for all our servers and I use it for my workstation. It is
remarkable.

So there is a reason why SM in many respects mimic Debian. :-)

Now, for the dependency stuff. I have looked at Debian but have actually
opted for a different solution than the one Debian uses to describe
dependencies. Yes, I know - sounds risky - but hear me out. I have
written tons of emails and postings about his model and I have also
discussed it in detail with many solid Squeakers at OOPSLA 2002
including Roel Wuyts, Doug Way, Ned Konz etc.

Debian relies on a numbering scheme majon.minor etc and then use
operators as you describe in combination with boolean algebra. Then
these dependencies are stuffed inside the package.

Problems:
- Having the dependencies inside the package means that you will need to
release a new version of the package if you need to revise the
dependency information. Even if the package itself hasn't changed!
- It also means that only the package maintainer can describe the
dependencies and all the possible configurations need to be "captured"
in one complex description.
- Using operators and boolean algebra makes the dependencies hard to
read, hard to get right and hard to analyze.
- It there is a conflict Debian can only barf at you and you essentially
have no good options. Sure, it doesn't happen often, but Debian is more
coarse grained and Debian can pretty easily have coexisting libraries
etc.

My solution:

- Instead of describing complex rules of what the prereqs are I opted
for describing "tested configurations". A "package configuration" in my
terminology is simply a list of the package releases that one particular
package release X works with. Say "RB1.2 works if the image has packages
Z1.32, Y1.0 and Q1.01". But this is not a description of *all* possible
configurations - it is instead a clear description of *one*
configuration that the developer has verified. Thus he makes no false
promises about the future version of Z,Y and Q etc.

- Then the package configuration is not inside the package RB1.2,
instead it is a Resource registered on SM and then linked (associated)
with RB1.2.

- Anyone can register these configurations. They are simply testimonials
that RB1.2 works in a specific configured environment. So RB1.2 may have
several of these.

- Finally, when a new release of a package is registered on SM I intend
to introduce the mandatory "compatibility level". It will probably be
just another Category, mandatory just like "License" is today. This
level will help the dependency engine when conflicts arise and can then
ask the user for decisions. If a given selection of packages (that the
user wants) ends up with the need for Q1.02 instead of Q1.01 then the
engine can look at the compat-level of Q1.02 and tell the user "Hey, I
need Q1.02 but it is marked as 'backwards compatible, only bugfixes' -
would you like to use that instead?"

Well, I will not have time to discuss this much more in detail - I need
both to work and try to squeeze in some SM time. I have written tons of
postings on the matter earlier - please check the archives. If the
questions/arguments are short and precise I can of course answer. :-)

regards, Göran