lex at cc.gatech.edu wrote:
> Stephan Rudlof <sr at evolgo.de> wrote:
> 
>>But I was talkin about "they had to give some hints about
>>*** how compatible ***
>>a package from one universe is in the other one" (see above!)...
> 
> 
> Right, and I didn't disagree.  Someone, or at least some program, has to
> do the work to determine that a new package can be used with the rest of
> the packages in a universe.
> 
> I do disagree with calling this "mixing".  Once you figure out that it
> is compatible, however that may be, you may as well add it into the
> universe for real.
> 
> 
> 
>>>not about how you measure
>>>it.  Instead of having an annotation on P that says "I seem to work in
>>>A", you can simply add P to A.  This is a very important point.  It is
>>>pretty much the definition of what a universe is.
>>
>>OK.
>>But you also have to add a compatibility measurement for each package
>>version for each new universe (as you have stated below, too).
> 
> 
> 

> No, I said something different.  Once a package is in a universe it's in.
> The auto installer can simply grab the most recent version of any requested
> package, because by definition all the packages in the universe are mutually
> compatible.

This is a serious limitation: if there are only two conflicting
packages, each working smoothly without the other being there, too, you
have to create a universe for each of them with all packages except the
conflicting one.
So for each conflict you need one universe more.
Note: there may be conflict cases of some *sets* of packages (you don't
need versions in your model, since you always would take the newest one)
not working together in the same universe (also needing the creation of
a new universe).

Another problem may be, that if you change the API of some package, you
have to define the result as another *new* package! At least for human
beeings this could be bad, but it should be possible to hide this mechanism.

> 
> What I said was that *if* you want to do compatibility codes, then you need to
> do them per-universe.
> 
> 
> 
>>>A third example would be if you remove a method that was deprecated in
>>>3.4.  That's completely backwards compatible in a 3.7-based universe,
>>>because no one is calling the method any longer, but of course it breaks
>>>compatibility in a 3.4-based universe.
>>>
>>
>>Your examples are good for illustrating my original point.
> 
> 
> I'm surprised.  Do you truly plan to have multiple sets of
> compatibilities for each version of each package?

No: at most sets of compatibilities for each package version.

There is needed one compatibility code/level for each package version
for each 'universe', e.g. compatibility stated for 'Squeak3.4' or stated
for 'Squeak3.5', there also may be something like 'Squeak3.4 and
higher'. You had to be *very* carefully with mixing the compatibility
measurements made separately for these categories.

> Goran's list of
> questions made it sound like the questions are asked just once, not once
> per universe.  Have you considered what the UI would be like?

Not so far.
But what about one drop down menu ('Squeak3.4', 'Squeak3.5',
'Squeak3.6', ..., 'Squeak3.4 and above', 'Squeak3.5 and above', ...) and
another one following for selecting the compatibility level?

> 
> As an extra challenge, realize that compatibility codes are not alone
> in varying by universe.  Consider the properties of a package in
> the universes prototype:
> 
> 	name
> 	version
> 	description
> 	url
> 	dependsOn
> 
> Fully four out of five make sense to vary from universe to universe:
> Names have different short forms, versions can be shortened as well, the
> description can go into detail on different points due to having
> different audiences read them, and dependsOn may need extra packages in
> some universes (e.g., LargeLists being required in a 3.6-ish universe).

It is true, that the dependency rules have to be stored universe-wise,
but they needn't be fully visible to the maintainer stating them. E.g.
expressing a dependency from a package version valid in different
universes could be made in one step for all of them.

> 
> 
> 
> 
>>>All of the above questions are easy if you know which universe you are
>>>talking about, and unanswerable otherwise.

>>>Thus, it seems that
>>>compatibility codes should be associated with (universe,package) tuples,
>>>not with bare packages.

I agree, if you mean (universe, package version, compatibility code)
tuples for the model in my mind (having package *versions*).

>>
>>Exactly (if packages are package versions/releases (I've been sloppy
>>here above, too))!
>>
>>But it is also possible to put these as (universeAttribute (e.g.
>>Squeak3.7), package version (!), compatibility) tuples in one universe,
>>isn't it?

Ah, I've written the above before...

> 
> 
> I don't understand the question.  A universe, the way I've described it,
> is a set of *packages*.  There should be more than one, and each image
> will participate in exactly one.

Just for the case 'version' has been part of the problem:
If you want to be able to express deps to more versions than just the
newest one, you need package versions. For automatically upgrading of
serving packages, while having and keeping packages written for older
versions of them installed, to compatible newer versions of the serving
packages (e.g. to fulfill some dep of a newly to be installed package),
you need package versions.


Greetings
Stephan

> 
> You can, of course, implement a universe object in a variety of ways.
> Pretty much anything that responds to #packageList will do.  It is worth
> considering carefully what the purpose would be, however, and whether
> a simple Set is not sufficient.
> 
> 
> -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