Stephan Rudlof <sr at evolgo.de> wrote:
> lex at cc.gatech.edu wrote:
[...]
> 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).

No, I meant per package version.

And it does solve the problem you describe.  The user makes one
selection at a time: install this, remove that, upgrade everything
possible, hold that package, etc.  Each one of these may be impossible
due to the dependencies being unsolvable, either because a depends-on is
not present, or a conflicts-with *is* present.  Whichever app they tried
to install first is the one that will be selected, while the one they
try second will generate an error and refuse to be selected.

And even without the simple extension, you are fine if either conflicts
are considered bugs, or if the installer will refuse to install
conflicting packages.

To generalize a little, there will always be more refined approaches to
versioning.  The specific versioning approach you use is orthogonal to
using explicit package universes.  Simple unversioned dependencies seem
to work fine, but there is also room for improvement.


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

Oh?  I guess it depends on the conflict and the installer.

Please remember, though, that as a general assumption, fellow
contributors to a package universe are generally working together.  At
some point, a conflicting package is simply rejected from the universe
if no one can make it work with the others.


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

I would call that situation forward progress, as described below, unless
the author wants to go to the trouble of making both web browsers
simultaneously installable.  For the forward progress situation, all
that is required is that the author support a transition period before
yanking out the rug.

If they don't provide a transition period, then they simply aren't
playing nice.  No tools can overcome that in the end.  All tools can do
is reduce the amount of niceness that is necessary.


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

Yes, I would say fix it.  Notice how narrowing attention to one package
universe at a time, means that you do not *need* to solve these problems
in a general case.  If you want your package in the communal universe
then you have to play nice and have your package cooperate with the
others.

If no one steps forward to fix the problem, then eventually the package
should be ejected from the universe.  This should be minimized, but it's
an option available as a last recourse.


> a set of compatibilities per package version;
>   but *not* in
> "multiple sets of compatibilities for each version of each package".
>  ^^^^^^^^
> 

Ahh, I (finally) see the difference here.






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

Yes, notice that "Squeak 3.4" is ill-specified by itself.  "Squeak 3.7"
makes sense, but in order to talk about "Squeak 3.4", you need to add
some extra assumptions.  In particular, what packages from SqueakMap do
you use?  The ones at the time 3.4 was finalized?  The ones that are
marked "3.4 compatible" on SqueakMap?  There are multiple correct
answers.

A universe would have one particular answer about such assumptions.  It
must, at any given time, define one set of packages.


Lex