Hi all!

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> I've been thinking about this some more, and I think SAR could be a good
> basis for a lot of cool installation magic, if we can replace preambles
> with conventions.
> 
> For example, any SAR created from a PackageInfo could include a member
> at a standard position that contains the package name. If this member is
> contained, then the following can be applied
> 
> > - The DVS tools know how to load a .st file. They do this knowing that 
> > they're working with a particular package. So they can delete 
> > methods, classes, etc. as needed.
> And -
> > You do get the package 
> > registered if you have DVS because of the line at the end that does 
> > (the equivalent of):
> > 	FilePackageManager registerPackageNamed: 'Whatever'.
> I note that the latter doesn't require DVSs' FPM, PackageInfo does this.
> As Avi noted in another thread, MC isn't the only tool that uses PIs -
> packages and extension related to them should be registered with PI.
> 
> And generally, this separates the format question (mc/sif/.st) from the
> issue of tracking what packages are loaded. If all package loaded are
> properly registered this also gives us a basis for allowing users to
> browse installed packages and remove them.
> 
> Daniel

This last bit is interesting. Currently SMSqueakMap has a Dictionary
registering installed packages (actually the history of all
installations through SM). PI doesn't cover all kinds of packages and
can thus only keep track of a subset of them. SM on the other hand can
keep track of all packages installed using SM.

So... Are these mechanisms dealing with the same "kind" of packages? SM
is about published packages. PI might be something else more aimed at
source code management. I don't know. Anyone?

If they truly are the same kind then it seems a bit messy to have two
independent registries. If they are different then each should be used
for the right thing.

regards. Göran