Fair comment but these things need to be balanced with an ease of deployment...
SARs are not there for that, Universes are close but require some discipline and has a lack of flexibility, similarly to MCs... 

A decent packaging system would make it single-click for end users and not far from that for deployers.

Each of SqueakMap/Universes/MC has their own merit but none bring it all together at the moment, IMHO.

Package integration is a complex problem, each of the above addresses some of the issues. It would be *nice* to have something unified (with end-user interfaces,  more friendly than Installer, perhaps).

Two quids worth (a penny doesn't go far these days :-) ).

Gary.

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org]On Behalf Of Chris
> Muller
> Sent: 27 June 2008 6:57 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] Squeak Package Management
> 
> 
> I think one thing that would go a long way toward making things easier
> is for the standard packaging tools (Monticello, Monticello
> Configurations, Universes, SqueakMap) to be delivered in **stable,
> working conditions** in base Squeaks downloaded from squeak.org.
> 
> The packaging systems are how Squeak users take the base environment
> and enrich it with other packages.  Therefore, it is crucial that
> these systems at least be able to LOAD things.  Unfortunately, this
> did not occur for a time in public (squeak.org) Squeak releases.
> 
> But please help me understand something:
> 
> > SqueakMap: Packages are out-of-date, because the security model
> > does not allow anyone to maintain the package; also, there are
> > no dependencies
> 
> As far as being out-of-date that's a human issue, not a software one.
> SqueakMap has a list of "Co-maintainers:".  So what is the security
> model limitation you are referring to?
> 
> Also, dependencies are not really needed with SqueakMap because it is
> superceded by SAR processing.  A SAR can do anything, like check if a
> certain dependent package is loaded, ask if you want a newer version,
> etc.  For Magma, its as simple as loading all of the dependent
> packages automatically from within the SAR script.
> 
> SAR allows something to be deployed exactly as the creator wants it to
> be.  The install script can pop up starting screens, documentation,
> etc.
> 
> I'll add, SAR works in 3.7, 3.8, 3.9, (3.10?), Croquet, etc.  Do the
> other packaging systems?
> 
> > Universes addressed the dependency issue, but still does not
> > allow widely distributed maintenance of the packages. So far,
> > it is kept mostly up-to-date, due to a few motivated
> > individuals.
> 
> By "addressed" do you mean it put a UI on it?  I did that too by
> simply adding a button to Monticello Configurations called, "Build
> SAR".  You make your configuration and, in one click, you get a SAR
> file deployable on SqueakMap.
> 
> Universes tries to make a "model" out of the dependencies is that
> right?  It portends to keep a record of "what works with what else"
> but that question is really ambiguous and impossible to answer
> universally or correctly isn't it?  Besides, running a successful
> *Test Suite* is my indication that packages are still working after
> I've loaded another package, not the official declaration by a package
> tool "works with XYZ".
> 
> Also, does Universes support, say, calling out to an external Internet
> site during package installation to grab latest resource files like
> SAR does?
> 
> My other gripe about Universes is the UI; it puts the software in
> charge of the user, forcing me expand and scroll a tree, manually
> hunting for a package whose name I already know.  Isn't there a way to
> *search* for a package?
> 
> > Sake/Packages is an attempt to address both of the above
> > concerns. It as yet has no UI. Unlike in SM or Universes, the
> > entire distribution is versioned as a whole, rather than the
> > individual packages, so editing one package means making a new
> > distribution version. This makes it easy to specify exactly what
> > version of the database your image is up-to-date with, but does
> > not scale if there are many contributions.
> 
> But "many contributions" would simply be accumulated before versioing
> up an entire distribution wouldn't it?  Just like Magma's process
> today; I post multiple individual packages to squeaksource multiple
> times before posting another Configuration..?
>