Stephan Rudlof <sr at evolgo.de> wrote:
> Assumed there are separated universes for stable and unstable packages,
> U_stable and U_unstable.
> 
> Now we put the union of these packages into a new universe U_all, but to
> know, where they have come from, we label each package with the name of
> the universe, from which it stems.
> As a result each package in U_all has a label #U_stable or #U_unstable.
> 
> 
> Now to my question:
> 
> I see no difference between the functionality of
> - a dependency resolver working in U_stable (or U_unstable), and
> - another one working in U_all *together* with a filter selecting the
> wished packages with label #U_stable (or #U_unstable), before starting
> to work.
> 
> Do you see any problems with this approach?

Yes, I agree that you could get the dependency resolution to work the
same here.  You can indeed implement a universe as a filter over a
catalog of everything, if you are careful.

It does lead to some complications, though.  Suppose the "TweakBase"
package wants to be called "Base" in the "Tweak" universe?  To make the
name-shortening work, you need to either let packages have different
names under different filters, or you need to make two separate entries
for "TweakBase" and Base".  The former case is complicated, and the
latter case seems to defeat whatever purpose there is of making
universes be filters.

It also does not give you the decentralization properties that the 2-day
universes prototype gives you.  It does not, for example, allow Disney
to have a private server for Fantasia 2007 stuff.

By the way, here's a little thing to think about from the Debian world:
few Debian package use the original upstream package bit-for-bit
identically.  It frequently, at the least, installs files into different
locations than the upstream "make install" would do.  If this happens in
Squeak, and if we implement universes as filters over an underlying
catalog of everything, then the catalog of everything will  fill up with
thing like "Chuck for 3.7", "Chuck for Tweak", "Chuck for 3.6", etc.,
which are all minor variations of each other.  That doesn't seem like an
improvement over handling all the "for foo" variants in separate
catalogs.

-Lex