Lex,
lex@cc.gatech.edu wrote:
Stephan Rudlof sr@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