Debian vs SqueakMap was: Pink Plane vs Blue Plane

Martin Wirblat mw.projanynet at SoftHome.net
Wed Feb 12 20:01:52 UTC 2003


Hi Göran and all 

> Just wanted to say that IMHO pink and blue can coexist happily *as 
> long as we have a good package system handling the dependencies and
> everything is turned into packages*. Period. Don't believe me? Then 
> look at Debian.
> ....
> BUT... if Squeak linger on in the monolithical world then sure -
> "battles" like this are inevitable to consume our energy.

I think you underestimate the most important thing:

A dependency-mechanism and packaging system alone is not sufficient. 
As you know at Debian 1000 people are working towards a release. Their 
main intention is to release something which is a whole even if it 
seems to be 10000 parts. For such a release they need as long as years.

Look at SqueakMap right now. People are putting up and removing 
packages in a not very coherent manner. They only work together in 
part, meaning for instance that if the final base image comes out, it 
is not tested centrally against all those packages or the other way 
round. It is not tested if packages harm each other. Now imagine we 
break vital parts out of the existing image and put them onto 
SqueakMap. Additionally you are encouraging people to put different 
versions of i.e. Morphic and Collections on it. Others are using these 
new clones for their packages. 

My prediction is, we will end up in a total mess. At least the 
development will become severely unefficient and building special 
distributions may even become ridiculous: Imagine that you need to 
load MorphicOld, MorphicNew1 and MorphicNew2 for your personal 
fullblown-everything-in-it-image! 

I think this 'Debian-comparable' process needs some strong guidelines 
and my guess what should be in these guidelines would be this:

There is a need for differentiating a 'base' from the 'rest'. The base 
could be a minimal image and packages which are now in the monolithic 
image. Allowed combinations could be i.e. package-sets which are put 
like onion-skins around the base image i.e. so that you get 
distribution 1, 2 and 3. All these have to be tested and made to work. 
They are thought to be maintained so that you can build on top of them.
Alternatively you could allow more freedom for the combinations as in 
the onion-model. But this would result in a much bigger effort to 
make every combination work. Just look at the current image, it is 
only 1 combination and everyone tests it, nonetheless some things 
seem to be broken in more than one final version! 

All maintainers of the other packages, the 'rest' ( everything on SM 
right now ), are not required to test or update anything, so there is 
a risk to build something on top of the 'rest'. 

There should be no 'basic' clones ( i.e. Morphic2 ) at all. And if so, 
they should live in a special area, neither 'base' nor 'rest', so that 
no one is tempted to build something on top of them. It really makes 
no sense to have essential parts duplicated with different 
characteristics. We have to shoot for the one that fits all - the best 
one. Every system which adheres not to this rule will slowdown 
exponentially in evolution speed as dealing with clone-overhead rises 
exponentially. Maybe it is an idea to have 'experimentalBase' for the 
next big version of base, but it must eventually replace the old base 
or has to be deleted, because every duplicate 'base' would be contrary 
to the idea 'one-set-of-parts'->'many-complete-wholes' ( it would 
become 'many-sets-of- parts'->'many-complete-wholes' ). 

This may sound overly restricted, but even if you think your 
dependency-system will work 100% and if it allows something to be 
loaded together, it will guarantee you a working image, I think there 
will be not many combinations which it will allow. If we mix the base 
and the rest, like SM intends to do now, we will end up with big gaps 
of functionality or uncertainty of functionality compared to the 
monolithical image. The base must be assembled and tested by hand and 
maintained and therefore the split between 'base' and 'rest'. 

The base would be equivalent to a Debian-release as is the image-
monolith now. I really think this is a very important concept - it 
gives you integrity! Perhaps we are all too accustomed to this very 
special advantage of the monolithical image, that we even aren't aware 
of it anymore. 

The long term goal is, to harden and broaden the base. Same as in 
Debian, they try to pack more programs in their release.

And as it is with an image or the Debian release the base will not 
emerge automagically just because we have dependencies.

regards 
Martin
 



More information about the Squeak-dev mailing list