package universes and filters question

Stephan Rudlof sr at evolgo.de
Mon Aug 2 23:55:34 UTC 2004


Lex,

lex at cc.gatech.edu wrote:
> 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.

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.

In both cases the base name of the package could be "Base" without any
problems.


What am I missing here?


> 
> 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

. The main one is parent of both local1 and local2.
Then you just need a possibility to build a union of local packages
belonging to local1 and local2 and the packages of main, and afterwards
you are running the filter. This could be accomplished by downloading
the package descriptions of main to the locals and adding the local
package descriptions to them (e.g.) before filtering according the
attributes.

Where is the problem?

> 
> 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.

I see it so: the package *releases/versions* have attributes saying in
which universe they make sense. One attribute per universe.

If you want to be more finegranular regarding installing locations: what
does this mean regarding Squeak? There are less files... Theoretically
you could also replicate install methods/scripts/whatever, one for each
universe, if this would make sense (again filtered by the universe
attribute). But this would be the same replication as you would have for
different universes (each universe its special script).

Again: where is the problem?


Greetings
Stephan

> 
> -Lex
> 
> 

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3



More information about the Squeak-dev mailing list