Stephen,

I agree with the SqueakMap stuff. However, another part of the 'packaging'
effort is refactoring the image and making large chunks of the image
'unloadable'. For me, that's problematic (ok, I think it sucks) ; what
happens is that you end up with a whole lot of different configurations of
Squeak. I'll give you a example:

- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.
- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the sake of
argument, let's say it introduces a problem in 32-bit color management. This
manifests itself as making IconicButtons invisible, and confuses FlapMorphs
in their layout when different fonts are assignd. Both problems in the stock
image.
- By coincidence, let's say that Zurgle happens to try to load itself in
32-bit color. People who download the SAR complain, and the 'reliability' of
the Zurgle package is questioned. User downloads Zurgle, it don't work.
- As another coincidence, let's say we have an image upgrade going from 3.4
to 3.5. (Zurgle package is still marked as 3.4 on SqueakMap, so it doesn't
show up under packages).
- User does magic incantation, figures out the 'show all versions' deally
and tries to load the Zurgle SAR.
- Squeak starts barking, "server not responding" error, though you can use
the download menu item to download the SAR.
-- This is a SqueakMap bug
- There's another problem;  compatibility with the StarBrowser package.
StarBrowser needs a little magic incantation to work in harmony with the
zurg.

As with any new image release, there are some problems. At the end of the
day, Zurgle comes out looking unusable, with which I have to agree.
Regardless of who, what, when, where or why it doesn't work. The feedback I
get, "Zurgle isn't a very reliable package". OK.

So, just like in the old days, I would hunt up the bugs and submit fixes (or
more likely whine loudly and the amazing Ned would magically fix them :-)
Submit them to the list with the appropriate tag. But here's the rub. Once
people start splitting the core image up, you can bet that whole silly
dependencies graph thing rears it's ugly head. To run this package you need
version 1.2 of this and 3.2 of that and 2.7 of the other thing. I'm not
close to smart enough to figure all that out. I couldn't even get my simple
package to work going from 3.2 to 3.5 when virtually no changes were
introduced within the monolithic image.

At the end of the day, what did all of the packaging stuff buy me? I'm sure
that there are benefits, I just can't think of any.

Jim



> Jim Benson wrote:
>
> >Bob Arning wrote:
> >
> >
> >>My dislike for the packagizing effort stems from:
> >>- it does not solve any problem that I face now or forsee facing in the
> >>
> >>
> >near future
> >
> >My sentiments exactly.
> >
> >Jim Benson
> >
>
> I sort of look at SqueakMap as a kind of Google for Squeak stuff.  It
> makes it very easy to find and install Squeak goodies that people create
> that are not included in the base image.  For me, that's the most
> important thing that SqueakMap does.  The packaging effort is nothing
> more than a refactoring effort.
>
> - Stephen
>
>
>