On Thursday 12 February 2004 8:43 am, Steven Swerling wrote:
> I have a large package, and I want it to make a minor change to a base
> system method. Namely, I want SystemWindow's passivate method to send a
> #passivated event. It seems innappropriate to reclassify the
> SystemWindow>>passivate method to be in my own '*mypackage' method
> category. With a SAR, I can put this small change in a separate
> changeset (in MyPackageInfo>>additionalChangeSets). Is there a way to do
> this in Monticello, too? (Sorry if this has been covered, I could not
> find a previous thread that addressed this scenario). Or should I just
> stick to SAR packages for distributing a package that needs to make a
> change to the base system?

I'd do this, and I'd also submit the base changes to the list as an [ENH].

Plus I'd try to make sure that I didn't clobber any newer versions of the 
methods; perhaps if/when your patch becomes an update you could check for it.

I've had problems when packages automatically loaded older code into my image 
(like when loading the BFAV and clobbering my patches to LargeLists).

Ideally, we'd have some way to track patches as well as packages as 
dependencies for packages. We deal with fairly fine grained patch submissions 
at the BFAV/mailing list level; it would make sense to give these first-class 
identities just like packages.

Would it make sense to represent patches and updates somehow in SqueakMap so 
that we could track this kind of package dependencies?