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
|