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.

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.



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

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.



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


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



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



Lex