Hi!

I have SNIPPed agressively below - but did so in order to try to pump 
Keith a bit on his new ideas. I have over the years also been involved 
in these efforts - I write SqueakMap, I had planned a new version with 
some interesting ideas around dependencies - and lately I wrote 
(together with Igor etc) Deltas etc.

Now I am curious about Keith's "conclusions" and of course, new ideas:

keith wrote:
[SNIP]
> What "we" need is for the package manager to be generating something 
> that is deterministic and reliable, so you can see what it is going to 
> do and what it did. Then mix and match stuff around, to create localised 
> alternative selection.
[SNIP]

I agree fully with the "what it is going to do" and "what it did". I 
would like to understand more about the "mix and match"-part.

> I have come to the conclusion that having dependency management is not 
> the way to go. Sure it is flash when it works, but when it doesn't, who 
> knows what happened in which order.
[SNIP]

This is an interesting conclusion. In my old plan for "SM3" I envisioned 
instead to collect "tested configurations" from people and use that as 
the base for "figuring out" how to combine packages etc. A kind of 
dependencies, but instead focused on "what works" and "what does not work".

Another interesting "scheme" I have seen is how the source distro Lunar 
Linux operates. It may be similar to Gentoo - but anyway, they have only 
"versionless dependencies". And they have only "one truth" at a current 
point in time - simply by having the whole catalog in Subversion.

This would have been equivalent to have SqueakMap with "versionless 
dependencies". I found it fascinating that it actually worked! My 
conclusion at the time was that - yes, it works because ALL users of 
Lunar sees and uses the exact same versions of all packages. So if a 
dependency is broken it is discovered very fast, and repaired.

Anyway... back to your conclusion - if "dependency management is not the 
way to go" - what do you envision?

> This is what I think the way forward for kernel cuis is. You distribute 
> images with everything interesting pre-installed. However the users can 
> by seeing the exact organisation of how the image was created, the user 
> can grab the bits he wants and assemble his image using bits of other 
> images. So the seaside bits published in a Seaside one click image would 
> be grabbable, and combinable with the bits from a Magma image, to make a 
> Seaside-Magma image.
[SNIP]

Ok... can you elaborate a bit on the "how" part of this? The grabbing 
and combining I mean.

> My new solution is based on 3 classes, an Export Target, an Exporter and 
> an Export definition.
> 
> (Export to: 'testing') purge fileOut.
> 
> Is all I need to do to save everything. Why didnt I have this solution 
> three years ago... simply because everything we are using is too darn 
> complicated, and we are so convinced we have some great tools that we 
> aren't bothering to think of simpler ideas.
[SNIP]

A clearer explanation of what the above snippet does and what the 3 
classes do would be interesting.

> I now have the same opinion of Monticello. Everyone is so busy using the 
> package version control that they have given up trying to find other 
> simpler solutions to the real problems.
> 
> A week of working in an image without Monticello and I am rocking!

Personally I think there are many, many schemes that work in "some 
fashion". So I don't dare to give judgement on any scheme. BUT I am 
interested in fresh and new schemes - and wondering about how they could 
change things.

For example, getting Deltas working 100% would potentially open up new 
possibilities in how to interoperate and how to mix and match code. 
Exactly in what way? Dunno! But it would be really interesting to find out.

regards, Göran