lex at cc.gatech.edu wrote:
> Stephan Rudlof <sr at evolgo.de> wrote:
> 
>>lex at cc.gatech.edu wrote:
>>
>>>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.
> 
> 
> No, I believe you could add conflict handling to the explicit universes
> approach.  Simply have a "conflicts" list on each package, and refuse to
> install or upgrade a package if its conflicts list prohibits it. 
> Simple, yes, but it seems sufficient for a normal universe without loads
> of conflicts.

If I understand you correctly, you would introduce a conflict mechanism
on a per package basis and not package version basis for universes.

This *extension* would remove the serious limitation mentioned above:
you wouldn't need a new universe for each conflict.
But it wouldn't solve the problem of different apps needing different -
conflicting - versions of the same package (also see below).

> 
> Actually, do we have any packages that conflict with each other right
> now?  I bet they are rare, which means it is actually reasonable not to
> model them at all.

> Just let the installer fail when it is attempted.

One problem is, that the installer mostly wouldn't be the point of
failure, if conflicts are not modeled at all...

> 
> 
> 
> 

>>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.
> 
> 
> That is one way to handle it, which seems fine in many cases.  If you
> have completely changed the API, then is it really the same package?

It depends.
There may be e.g. a WebBrowser package with general features *and* some
API; some packages may need the general features, others the API. For
the ones needing just the general WebBrowser features a change in the
API would be no problem.

> 
> Alternatively, you can simply treat it as forward progress.  Consider
> the case where deprecated methods get removed, as one example.  With
> versioned dependencies, you gain a headache in this case, but with
> unversioned ones you simply assume that almost everyone will grab the
> newest version of everything anyway.

World is not necessarily so simple: if a common used app is not
compatible with the newest version, then many people wouldn't want to
upgrade (in spite of some new app just wanting to have the newest
version)...

You would say: then you have to fix it! But what if the fixing takes
time? Or nobody does it (for whatever reason).

> 
> 
> 
> 

>>>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',
> 
> 
> The above two sentences seem directly contradictory to me.  I will go
> with the latter, because it seems to be what you are suggesting.

What is contradictory here?

One compatibility code per package version
  multiplied with
number of universes
  results in
a set of compatibilities per package version;
  but *not* in
"multiple sets of compatibilities for each version of each package".
 ^^^^^^^^


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

> Note that the universes model helps here with the mental complexity of
> having different compatibilites, names, dependencies, etc. in different
> universes.  At any specific time, a developer should be working in one
> universe, and that universe sets a context for everything they think
> about and everything their tools do.  That's why it's called a
> "universe".

I think I understand your point: at least I've started to use your
definition of 'universe' as a replacement for something like
'Squeak version, or set of Squeak versions, or one of the former with
some restrictions or enlargements...'.

> 
> 
> 
> 
>>>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?
> 
> 
> Yeah, it sounds like it must be something like that, especially if you
> add something like this to handle bulk settings:
> 
> 
>>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.
> 
> 
> 

>>>>>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*).
> 
> 
> Yeah, I think that would be the same thing.  I was thinking of them as
> tuples like:
> 
> 	((universe, package version),  compatibilite code)
> 
> But there are many ways to slice it.

Sure. E.g. (package version, (universe, compatibility code) attribute).


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