Hi guys!

I have been converting my desktop to Debian Linux and thus have been getting even more exposure to
the Debian package system.

(I have also felt a bit guilty for not helping out Henrik with the modules. :-))

The package system of Debian is quite advanced and proven (as some of us have stated before on
this list) and should be able to provide us with some hints to what we should do with our Modules
system in Squeak.

Ok, this is written hastily, so bear with me. :-) There may also of course be errors here...


Dependencies
============

Debian: Each package (specific version) explicitly names what packages it is dependent on
(specific versions).

Squeak: This is the same as the list of "external modules" of a module. It is important to note
that whenever we talk about a module we mean "a specific version" of that module. And the
references to external modules are thus also references to "specific versions".


Streams/releases
================

Debian: Debian has three "fronts" similar to our alpha, gamma and "offical". They are called
"stable", "testing" and "unstable". Just to make life a little bit more fun the specific versions
of these fronts are given names. The current "stable" is called Potato (after Mr Potatohead in a
certain film...). "testing" is called Woody and is going to become the official "stable" soon (or
something). "unstable" is called "Sid". It goes something like this: Everything is happening in
"unstable" and it can surely go boom. When stuff seems to be working those new versions of
packages are released into "testing". This means that "testing" is pretty up to date but not rock
solid. Then after a proven time in "testing" without any bugs reported it goes into "stable".

Squeak: Well, currently we have something similar - but we lack the "module" granularity which has
made it problematic to maintain the gamma and the offical relase ("stable" and "testing").
Eventuall we all end up in the alpha stream! :-) This is not so good, but I think it would be much
simpler if we where dealing with new versions of modules instead of with small changesets.


Conflicts
=========

Debian: Each package (specific version) can name explicitly other packages (specific versions)
that it is known to not be able to coexist with.

Squeak: ?


Basic metainfo
==============

Debian: I don't have it in my head, but each package has a set of basic meta information like
author, homepage, short description, long description etc. Take a look at
http://packages.debian.org/stable for examples.

Squeak: ?. We should also define such a minimal set of metainfo that each module should have. 


Cache of packages
=================

Debian: All packages are downloaded and cached on the machine.

Squeak: Henrik talks about a local cache of modules so I think this is accounted for. I am not
sure though.


Cached database of package info
===============================

Debian: "Apt-get update" fetches compressed indices (if they are not up to date) of all available
packages from each one of a set of "sources" that you list in a "sources" file. This way you have
locally a database of all "known" packages to your machine given the set of source locations
(ftp/http/cdrom etc).

Squeak: Hmmm. There have been thoughts about it:
http://minnow.cc.gatech.edu/squeak/2049
We need something like this I think. And, to be concrete:
We should define an offical list of "top servers" (but you could add your own of course, compare
to Debian's "sources.list") that together form the top of the complete virtual Squeak module
hierarchy. But since we still want anyone to be able to setup an ftp-server for their own modules
I think we could introduce some form of "forwarder" file in order to make the virtual hierarchy
distributed.

An example: Let's say I have a module #(People gh sqcvs). One way would be to store my stuff on
one of the top servers (probably at SqF). But I would also like to just stick a "forwarder" there
at "gh" which says that, "Hey, gh is not here. He has his modules over there:
ftp://ftp.bluefish.se/gh/". Then if someone tries to load #(People gh sqcvs) Squeak would:

1. If no cached info is available at all: Visit the "top servers" one by one and load their
index-files (just like "apt-get update" does in Debian) and store this in a local database
structure.

2. Check the database for the module #(People gh sqcvs). If not found, back one step up and look
for #(People gh). This would resolve to an url, say: "ftp://modules.sqf.org/People/gh". Then we
load "ftp://modules.sqf.org/People/gh" and voilá! We find a forwarder to
"ftp://ftp.bluefish.se/gh/". We go there instead and since it is a new location we load the
index-file (this could of course be done differently, but perhaps it would be good to demand that
there always is an up-to-date index-file available on each "location"). Then we can finally, given
the new index-file with info on all modules available there, resolve sqcvs to
"ftp://ftp.bluefish.se/gh/sqcvs" and off we go to download the actual module.

The scheme above would mean that we can, by placing a forwarder at a "parent" server - make a link
to another ftp/http server on another machine and still maintain the virtual hierarchy of modules.

Ok, braindump ends here. Hit me.

regards, Göran


=====
Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
"Department of Redundancy department." -- ThinkGeek

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com