goran.krampe at bluefish.se wrote:
> "Lex Spoon" <lex at cc.gatech.edu> wrote:
> [SNIP]
> > If there is a better way to handle dependencies then let's do it, but
> > name+version seems to be a fine way to go.
> 
> I was more intending to go for UUID + version. So that packages are free
> to change their names.
> 

Incidentally, you *can* change package names without having the UUID. 
People do it in Debian by having a transition period where both packages
are present and the new one "provides" the other one.  It's more than
trivial, but it's still not that big of a deal.  The nice thing is that
all the tools can just immediately display and modify package names,
instead of having to look up in some global table what all the UUID's
mean.

But, it's not a big deal.

Incidentally, here's some info about the Debian packaging and dependency
approach, including the list of dependency fields:

	http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-pkg-bas
ics

It's probably worth looking at this before finalizing any new packaging
plan.


> > And at any rate, as you say forks are a long way off -- mostly everyone
> > is happy with SqueakMap right now.
> 
> Yes, a good side effect indeed. And when SM1.1 is in place and we can
> attack the dependencies for real I think the reasons for forking will go
> away even more. And then when Craigs kernel work finally gets folded
> back into official Squeak (whenever that will be) there will really be
> very few reasons to fork.

I dunno if technology can really help with forking.  Forking is more
likely to happen over something like whether ANSI compatibility matters
or if it's okay to completely change the underlying language, or whether
we should just live with SqueakL or rewrite the Apple parts of Squeak
from scratch.  No technology can avoid this kind of thing -- if it
happens, the packages would simply be different.


Lex