Alex writes:
> Why not to have a class Package intended to replace PackageInfo ?
> This class package would have variables such as name, classes, methods, comment, and
> eventually postDoableAction. This is what I propose in the changesets I posted.

I actually like the PackageInfo approach of using category strings,
instead of having an explicit list of classes, methods, etc.  It makes
the packaging approach integrate nicely with the browsers.  It seems
more confusing than useful, to have classes that are in category "HTML"
but in package "Scamper".

I was actually going to suggest naming it Package, myself.  Why tack
"Info" on the end, when all classes hold information?  But there are
enough flame wars going on already.  :)

I could not load your code, unfortunately, Alex.  I am using a 3.8
image, with Monticello 183 loaded.  Did anyone else have luck?


Going forward with something based on PackageInfo, I mostly want the
basic functionality of things like #classes to remain predictable.  The
reason is that there is potentially more to a package than loading and
unloading, and if everyone starts making random subclasses, then loading
and unloading is all it will ever be.  Further, even loading and
unloading can run into problems, if the custom subclasses use code that
depends on the particular version of Squeak!

But, if people are attached to subclasses, it can certainly work.  Just
please let us commit, at least, to the category strings style of
packaging.  

A few people have asked why a package should have meta-data before it
gets uploaded to a public server.  In general, I agree that the
appropriate meta-data may be different.  However, all of the following
items make sense to me:  author, homepage, and comment.

Per-image packages are not only hacks that the image's owner has just
started.  They can also be things that were given to them by an
officemate.  They can also be packages that are being used privately
within one small group project.  In all of these cases, author, url, and
comment are things that would be great to have attached to the package
information.


Regarding dependencies, please notice that simple dependencies work well
in package universes, and seem to work even better within a single
image.  A simple Set of String's is all you need.  If the general group
is willing to add depends, provides, and conflicts to the per-image
Package class, then I should be able to modify package universes to use
the same Package class (and same Package objects) that are used
per-image.  It is not critical though; I can leave it using its own
custom class if adding these instance variables seems like too big of a
step.


Regarding the difference between PackageInfo and SMPackage, I don't view
this as a "shortcoming".  SqueakMap, by design, has packages with
pointers to data that live on the public server.  That's not a
shortcoming, but an intentional design feature.  It's a tool that does a
different job than an in-image PackageInfo and UPackage.


So, my summary of desired directions at this point:

	1. Commit to the category strings idea.  Subclass PackageInfo *only*
(if ever) to add load and unload code.

	2. Add maintainer and comment fields to PackageInfo.  (Maintainer is
more important than author, and is also better defined.)

	3. Flesh out a serialized package format, complete with load and unload
code and all the fields of PackageInfo.


My desires also include:

	4. Add to PackageInfo: homepage, depends, provides, and conflicts


-Lex