Debian vs SqueakMap was: Pink Plane vs Blue Plane
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Thu Feb 13 10:29:21 UTC 2003
Martin Wirblat <mw.projanynet at SoftHome.net> wrote:
> 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.
Agree. Even before I have read the rest. :-)
> 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
Well, we have been talking about "preserving the notion" of the image by
"blessing" packages as being fundamental core packages that the
community takes a shared responsibility for.
And in that collection of packages there will most certainly only be one
And that collection needs of course to be tested together so that there
are no conflicts etc.
> 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
Oops, you where coming to that. :-) Well, anyway - then you know that we
have been thinking in these terms.
> 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!
Yes, I would probably settle for one onion skin to begin with.
> 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
Nah, I don't agree with this one. I do agree however that it should be
clearly noted that hey - this is Morphic2 - proceed at your own risk
etc. Rebuilding core parts may very well turn out to be a very
interesting area - we are doing it all the time, Nathanael has rebuilt
Collections, people are thinking of rebuilding Scanner, Parser etc. And
sure, we can mark these "core clones" as being that and thus clearly
"dangerous ground to stand on". But we can't forbid anything.
> 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' ).
I think I am putting a bit more trust in "evolutionary" forces here.
If someone creates Morphic2 and it is vastly better than Morphic,
packages may start using it and sure, those packages are paying a high
price because they will not be able to coexist with other packages based
on Morphic. Either they will die, move over to Morphic or... Morphic2
will turn so popular that this disadvantage doesn't matter to the users.
In that case we have competition and one of the two will probably win
out because the community isn't large enough to accommodate both.
Or they will merge.
IMHO we can't possibly "forbid" people to produce Morphic2. Instead SM
(with dependencies etc) should provide a good playground for the
packages to "fight it out" in an orderly manner.
> 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
Nah, it doesn't really intend that - currently we are focusing at
breaking the image apart.
When we succeed (we have only scratched the surface yet) then we will
definitely "bless" packages as Squeak core etc I guess more or less like
But I don't agree with forbidding stuff etc.
> 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'.
Yes, well, that is one difference. There are probably others too.
> 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.
I can assure you that I am aware of this. :-) And I fully share your
> 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.
More information about the Squeak-dev