Stephan Rudlof <sr at evolgo.de> wrote:
> lex at cc.gatech.edu wrote:
> > 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.  
[...]
> In spite of this I don't see a problem here.
> Packages exist in different releases/versions.
> 
> Normally, I think, one release of "Base" exists in just one universe:
> eg. "Base_4.1.2.3" in just universe U_1; having a label #U_1 for the filter.
> 
> Now to the more complicated case of a package release (one version of a
> package) belonging to *two* universes: then you just have two labels,
> say #(#U_1 #U_2) to flag this release as belonging two two universes.
> The filters have to be written to deal with collections of labels, of
> course.

I agree that this could work, once some details are fleshed out.  I am
simply saying it is more complicated.



> > 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.
> 
> Why not?
> 
> Assumed there is one main server and two local ones:
> 
> main
> 
> local1  local2
> [etc.]

Yes, but this is an extra feature beyond what you described above.  Note
my wording carefuly: it does not *give* you the decentralization
properties in itself.

If you are willing to have multiple servers, then I see no advantage to
the design you described with #U_1 labels, etc.  Once you allow multiple
servers, you can set things up like this:

	main-3.4-stable   main-3.6-stable    main-devel  tweak-devel


Now there's no need for the stuff you describe about packages having
multiple names, descriptions, dependencies, etc.   You can use simple
package descriptions.  If different universes want a minor change to the
package description, then you simply post a slightly different package
descriptions to each server.




-Lex