Hi Martin!

Martin Wirblat <sql.mawi at t-link.de> wrote:
> Hi Göran,
> 
> >"updated every time a new version of a prereq arrives" ??
> >
> >Personally i want the dependency system to describe "verified working
> >configurations" and nothing more. Rules like "any version later than 
> >x" are IMHO not so good.
> 
> In a notion of verified working sets with specific packages, something 
> like this will happen: package A needs C-1.5 and package B needs C-2.0.
> You want to have A and B in your image. Now your are stuck. Perhaps 
> both would have been happy with C>1.0 . 

Yes, of course conflicts will arise! But there are two things that will
make this work (I have described this tons of times, I really need to
put it on a webpage):

1. A packagerelease can have *multiple* working configs. So if A and B
worked with C-1.0 that would be known in other configs. And the engine
could find that! This is very important. So if at the time of release of
package A there was C-1.0 and C-1.1 available, the maintainer (or
others) can test both and simply register two working configs. But they
*should not* claim that package A works with C-2.0 because that version
*does not exist yet*. They simply can't predict the future.

2. If there is still a conflict another basic idea of mine comes into
play: "compatibility level". I want to force PackageReleases to declare
how "backwards compatible" they are. I have a list of 6 levels - but we
can discuss those of course. But just as an example - if C-2.0 has
compat level 1 (=No change actually, just better class comments etc)
then the engine can tell you that and offer you to use C-2.0 with
package A and it would not be a problem. If the level was 6 (=The API is
totally changed, no chance in hell that dependents will work) then the
engine can tell you that and you would realize that you are stuck.
BUT... the engine can also tell the developer of package A that he/she
probably should upgrade because the dependency on C-1.5 is creating
conflicts!

> But if you want to, you are able to describe a specific package with 
> name+version too. 
> 
> >I agree. I am all for "simple" solutions like for example "prefix" 
> >based namespaces. I have been planning to introduce "Person" in SM 
> >which could mean that we can have entries for developers. We could 
> >add signing etc and keep the developer "sig" in there too. Having 
> >that it would be trivial to start using the "sig" as a prefix/suffic 
> >to get guaranteed unique names:
> >
> >SharedStreams-gh
> 
> I must say if we really use PackageName_GlobalName as 'simple name 
> spaces' I dislike this idea. PackageName should be chosen as you said: 
> short, meaningful, without spaces, just like other Smalltalk 
> identifiers ( we are going to code with them = we have to speak them ).
>  
> BTW, what if not the package rather than the author wants to change 
> his name? :) 

I am not sure what you are saying here. You dislike the idea - but what
did you want instead? 

> Is it not a bit farfetched to envision SM distributed to a hierarchy 
> of servers? And if this should really be necessary in some distant 

Nope, definitely not farfetched IMHO. We already have it! Your map on
your harddrive is already a "slave server". It's just readonly.

> future, don't you think a central 'nameserver' working with this 
> hierarchy would solve this? There are decentralized data structures 
> out there relying on some central part, which are much bigger than 
> SqueakMap ever will be. 

What I want to have is company/group/personal SM servers. That can work
offline. I want to be able to have "local" packages that noone sees
until I push them upwards to a chosen master. It is not farfetched -
when you think about it there are quite few places in which conflicts
may occur.
 
> regards,
> Martin

regards, Göran