cg at cdegroot.com (Cees de Groot) wrote:
>  <goran.hultgren at bluefish.se> said:
> >Note also that SM handles "off line" pretty good - the map is in a
> >single file and can be loaded directly from it - no need at all to be
> >online. So if you have 134 package files then you just need one more
> >file to have all the dependency information - the map file.
> >
> Well, I'm sorta hoping that this gets unwieldy soon due to the success
> of the project ;-). An in-between solution would be to have a 'stripped'
> SM format available for download, with just the dependency assertions
> (you could probably give packages binary codes for this format so you
> have just loads of binary pointers in a compacted file - I guess you
> could store all CPAN's dependencies in under a Meg this way).

Yes, we could definitely do something like this.

Note: I agree with you that it somehow feels "nice" to have the
dependencies inside the package file, but when adding it all up I think
the positive effects of having them outside are more.

> >And I typically think that dependency management should be handled
> >declaratively (not as running scripts inside the packages) as much as
> >possible - otherwise we can not have "global" analysis of dependencies
> >and conflict detection.
> >
> Agreed. 
> 
> >Yes, this is why a package configuration has a person signing it (well,
> >not digital signing - perhaps later). This gives the user the
> >possibility of saying "Load package X, latest version being at least at
> >beta level, with prereqs recursively and only trust configurations from
> >the package maintainers."
> >
> Why later? It's not that RSA is exactly *hard* in Smalltalk ;-).
> (just kidding, I understand that your SM to-do list is currently
> approaching the size where you are considering publishing it in
> a two-volume leather-bound format...)

That is exactly the only reason. :-)

> >That would be... 6Mb I think. I am not worried. :-)
> >
> Tell that to the IPAQ guys :-)

Good point. But 10000 packages are A LOT. Before then we can surely come
up with even tighter representations - we could even let you download a
submap only covering selected packages and only containing the
dependency information (as you mentioned above) - if we have that then
surely the size of the packages themselves will be the problem - not the
1 additinal file with the needed dependencies.

regards, Göran