On Wed, Dec 11, 2002 at 04:50:21PM -0500, Brent Vukmer wrote:
> You replied:
> >And downloading packages without worry about
> >conflict.  
> 
> If a new image becomes quick-n-easy to build, then conflict becomes no
> big deal.  Do some quick diagnosis then build afresh! 

But what if you want to use two packages in your everyday Squeaking, but
they conflict with each other?  Using two images is not a satisfactory
solution.

> Also I would
> rather diagnose package conflicts here then in a multi-namespace image.

But there is no conflict in a multi-namespace image, at least in the
(most important) sense that packages that would stomp on each other in
(A) would coexist and function properly in (B).

> >Also, having multiple packages in the image available for
> >analysis, that would be conflicting in (A) and therefore not both
> >visible.
> 
> I'm trying to imagine a sample scenario where running multiple package
> releases in the same image would be helpful in development...  

What about unifying the underlying code of two packages that conflict?
In (A), you'd have to run each package in a different image as you made
changes to each so that they would be consistent.  In (B), you wouldn't
strictly NEED to unify the code, but if you decided to (in the interest
of elegance and orthogonality), it would certainly be easier within the
same image, especially since tools could be built to specifically support
this kind of work.

<snip>

Joshua

> 
> 
> Cheers,
> Brent
> 
> 
> 
> 
> 
>