manuallly controlling dependencies, at least for SAR

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu Nov 28 07:42:56 UTC 2002


"Jeff Sparkes" <jsparkes at databeacon.com> wrote:
> > Again - you can do this today using "load scripts".
> > 
> > I don't want people to add stuff like this "inside" the 
> > packages though
> > because that will lead to problems later. The packages should be
> > "clean"! So, what to do then? Simply write a .st file that uses the
> > SqueakMap API and register that file as a "Dynamic/static load script"
> > on SM.
> 
> Oh.  Now I understand.  Is there a "how to build a SqueakMap package"
> anywhere?  It should be reachable from http://map2.squeakfoundation.org/sm/

I think I added a link to the minnow SqueakMap page there. Hmmm,
probably lost it when I needed to recover the server the other day. Ok,
it's there now.

> I can start a page on minnow later today, but maybe someone else should
> write the first draft, since I'm obviously not a guru.  I don't think I've
> read all the information in the mailing list, so it's time to go check the archives.

It would be really great if you could help us with this! Regarding
packaging - it's only .sar and DVS that are "tricky" I guess, the other
formats are well known. Start writing and we will help out.

> The odd thing is, I don't even have a package with dependencies...

:-)

Again - perhaps I didn't explain *why* I don't want the dependencies
inside the packages. There are several reasons:

1. Putting it in the package would mean a change in dependencies needs a
new release. Creates cascades of new releases for no really good reason.
2. It also means that the only person able to describe dependencies for
a package is the maintainer.
3. Finally - the big one - it means that there can only be *one*
description of dependencies. Typically I would instead want us to
describe "verified configurations that work" for a specific package
release. There can be several of those. And it isn't at all likely that
the maintainer knows them all.

If this is unclear I can explain further but it is easier if you check
the archives - I have written about this including examples before.

And a final note: In the upcoming SM 1.1 there will be a general
mechanism for "resources" that can be linked to package releases. This
means we can adopt different mechanisms for dependency management since
it will actually not be implemented "in" SM but rather on top.

I will then put my idea of "package configurations" on top and implement
a little "dependency resolution/conflict detection" engine as a separate
package.

regards, Göran




More information about the Squeak-dev mailing list