Thanks for the note John.  I hope you don't mind if I cc the
squeak-dev list in my reply.

> Hi Chris, a little bug notice which I hope you might be able to help with:
>
> I'm trying to get OmniBrowser (incl Refactory, Shout, etc) +
> OCompletion installed in Squeak 4.3 (or 4.4), which seems a reasonable
> baseline for development -- shouldn't any new release have these
> packages validated.  (Plus, what other "5 star" dev tools do you
> recommend?  Besides Magma of course :) which I see is in the
> SqueakMap, yay).
>
> After many attempts, I am not able to get OmniBrowser working with
> OCompletion in 4.3 (or 4.4 which I totally gave up on and went back to
> 4.3 where I got a little closer).  The SqueakMap packages are
> conflicting, and several attempts at tracking down custom/patched
> installer scripts is not helping.
>
> Can you advise me a proper sequence starting from the 4.3-All-in-One
> image on squeak.org.  And then hopefully forward  the right scripts
> into SqueakMap.  Apparently everybody else but me has got their own
> private scripts working, no problem :)  but it seems they are not
> working off the stock release images.
>
> By the way, I think it's (way) too confusing to have so many Squeak
> distribution points, as discussed at wiki.squeak.org/squeak/5878.  Why
> is there SqueakMap + SqueakSource (+ Metacello, + ConfigOf, +
> Help.ExtendingSqueak scripts, and the many private scripts and
> repositories floating around, etc).
>
> There should just be 1 master package listing/repository system, which
> is usable both for end-users and developers.  Every component/project
> should have a stability level (stable, testing, development, sandbox,
> throwaway, ... )  It should be an app (e.g.  SqueakMap category
> browser), that just filters out various release levels for the end
> user installations. I understand this is what SqueakMap is aiming for,
> but there seems some disconnect, that few/nobody is forwarding their
> material into it (?).  Only a dozen or so validated packages for
> recent releases like 4.3, 4.4.  And now there's Metacello, differing
> how?  And these ConfigurationOf...  scripts doing what?
>
> I don't understand why there are so many different tools/repositories
> apparently jockeying for "top" package manager.
>
> In particular the distinction between SqueakSource and SqueakMap seems
> broken. Why should somebody have to be manually picking things up from
> SqueakSource and replicating into SqueakMap.  Either this should be an
> automatic link, or everything should be directly in SqueakMap to begin
> with.  Is there any legitimate basis for these being 2 places?  What
> is needed to unify/integrate them?

You forgot to mention SqueakSource3, and SmalltalkHub, and Git, and...

Multiple packaging tools is a reality that can't be denied -- so we
have to deal with it.  But I don't consider SqueakMap a member of that
group.  It's just a Catalog which was intended, from the very
beginning, to be precisely what you said (quoting again):

> There should just be 1 master package listing/repository system, which ...

Unfortunately during discussions features often get conflated with
requirements and cause the discussion and progress to get off track.
For example, when you mentioned:

> Also desperately needed is better versioning and dependency
> declaration and tracking -- is anybody working on that?

the very first thing I want to ask is "why" do we need "dependency
tracking?"  The answer is we want it so Consume can be a one-click /
one-line-of-code affair, not because we need dependency tracking.

In 2011 when this very discussion was raging, I captured and
documented requirements for the two primary use-cases a Catalog should
serve:  Consume and Publish.

  http://wiki.squeak.org/squeak/6183

I didn't have a lot of time to revamp the whole system, so I designed
a set of guidelines that, if merely followed, would allow all of the
requirements to be met.

  http://wiki.squeak.org/squeak/6182

I then made the minor enhancements to the SqueakMap client and server
so that following the guidelines would be as painless as possible.
The result is, if each Project will take just a few minutes for each
just once for each release of Squeak:

  http://wiki.squeak.org/squeak/6180

then each Author can maintain what you said you want and what I
believe the community *needs* -- a master catalog "App Store" of
software available for Squeak that _works_.  Something that allows the
community to inject power into itself by enabling our work on each
other.

So, as part of the last few Squeak releases I reached out to fellow
community developers publicly and privately to ask them to update and
check their SqueakMap entries for the new release.

These efforts have not been met with widespread acceptance.  It seems
like this discussion is constantly coming up but some folks would
prefer spend 10 minutes talking about it again and again than 5
minutes to just paste the script into the SqueakMap entry so it will
Just-Work(tm) for the the community.

I want to be very clear -- the important thing for me is NOT
"SqueakMap" (I hated working on it) but having the Consume and Publish
(and Collaborate) capabilities working in the community.  Again, I
care about requirements being met not what tool is used.  Can't we all
just agree we want a Catalog and, until someone else produces
something better that can meet the requirements, let's get as much
utility out of this SqueakMap bastard as we can.

I myself follow all of the guidelines -- when I moved Magma from
SqueakSource to SqueakSource3 I didn't have to say a word to anyone
because I just updated the SqueakMap entry.  It's a Map.  "Install"
just kept working.

> Also desperately needed is better versioning and dependency
> declaration and tracking -- is anybody working on that?
>
> Many thanks if you can help me get the OB + OC working.

If Colin and/or Levente are willing to provide the scripts for 4.3,
4.4 or trunk, I'm willing to spend the minutes to paste them into a
SqueakMap entry and hopefully put this to bed.

Best,
  Chris