package universes and filters question

lex at cc.gatech.edu lex at cc.gatech.edu
Fri Aug 6 20:55:54 UTC 2004


I don't mean to split things off.  I actually proposed these ideas as
future directions for SqueakMap, and only implemented them when you
argued that they are bad ideas.  Most any future direction is fine with
me, at this point, so long as we please use simple working solutions
until something better comes along.

Some possible directions I'd be very happy with:

	1. SM could incorporates the universes model somehow.  There is just
one important idea that keeps this from going smoothly; see below.
	
	2. You or someone else could pick up the Universes code; it doesn't
need to be me at all, and in fact, I'd rather it were not me.
	
	3. SM and Universes could have crosslinks between them so that it's
easy to post to both of them simultaneously.  This would be a handy
addition to SqueakSource, for example.


In the meantime, I certainly suggest that people keep posting stuff on
SqueakMap no matter how much they use Universes.  They are complementary
tools.
  
I also intend to create a 3.7 stable universe in the next few weeks,
because this is something Universes would seem to work well at, and it's
something that will give people a good idea of how Universes works.

For the development stream, the best strategy is harder to see.  I'd
guess that dependencies are a major thing to think about, but the
conclusion you draw depends on how your and Stephan's dependencies come
along.  Let's leave aside that discussion for a future email, because
there's something more important I'd like to talk about.


Please consider carefully this one issue: does *everything*, down to
every last minor variation of every package anyony posts for any purpose
whatsoever, really need to be in the same index of packages?  As a mind
experiment for what this map will be like, imagine from the Linux world
that someone made a big index holding every package in every version of
Slackware, Debian, Redhat, Gentoo, and OpenBSD.  My mental picture of
this has a lot of minor variations of most packages.  There will be a
dozen or more gcc-2.95's.

As another mind exercise, suppose we made a universe that includes the
current frontier of SqueakMap's packages.  This would not include every
package, but it would include one or two version of quite a lot of them.
 In particular, it would include everything that one can currently
reasonably expect to be installable into a 3.7 image.   Every 3-12
months we could fork off a stable universe that only receives bug fixes
and which has any horribly broken stuff removed from it; the unstable
universe would continue on and would still have all of the same packages
in it.

Doesn't the first scenario sound a little hard to manage?  And doesn't
the second one sound just fine?  In the second scenario, users in both
stable and unstable images would see precisely the set of packages that
are reasonably maintained and installable.  Hackers that additionaly
want to see unmainained packages can still do it, though they must work
a little harder and use some sort of "multiverse browser" or access a
catalog of everything.

I ask about this one issue because if you let go of the idea of having
absolutely everything in one index, then the rest of the universes
approach seems to mesh very nicely with where Squeak Map seems to be
going.  It becomes straightforward to let maps be merged into larger
maps, and to let non-central maps be locally administered with their own
accounts and policies.  We could then have simple dependencies, stable
releases, mixin servers, private servers, and local update policies, all
without requiring any further cleverness.

Finally, let me be very clear on one other thing: all of the efforts on
things like dependencies, interfaces, compatible updates, branching
versions, and simultaneous loading of multiple versions, are still very
important no matter what we do in the short term regarding package
catalogs.  The present discussion is just about what the next step or
two should be.


In summary, I would be happy to have one tool or toolset we all agree on
using.  But while the really great Grand Unified Tools are still being
developed, shouldn't we use simple existing solutions and make do as
well as possible?


Regards,

Lex Spoon



More information about the Squeak-dev mailing list