Goran, I hate to complain about work that is perfectly fine and that is
very valuable for Squeak.  But I will anyway.  :)  I want it to go as
well as possible!

Basically, I am worried about one main issue.  It's the idea of "tested
configurations".  I have some experience in Debian, and there it is HARD
to assemble tested configurations.  It typically takes around a year
(very roughly) to assemble a set of packages that is tested to work with
each other.  Even then there are almost always updates as time goes by!

Unless there is something different about Squeak, it is entirely
impractical for people to assemble tested configurations on a regular
basis.  It *is* proven to be practical to simply depend-on the packages
you need -- without mentioning specific versions -- and for everyone to
use the newest version of everything during a development stream. 
Usually everything works fine, and when there is a bug it gets fixed
quickly because these are easy things to fix.

When the time is ripe, you certainly can build tested configurations by
freezing all updates and focussing on fixing up the bugs with
interactions between the packages.  However, this is a major affair and
I don't see how it could be done on a regular basis when dozens of
developers are all updating their packages all the time.

Following from this argument, I wonder who other than a package's
maintainer is going to muck with dependencies?  First, it is hard enough
to find a single maintainer for most packages.  :)  Second, it is
impractical to take a package and then mix it with other packages than
the ones it was developed for.  Almost all Debian packages have at least
one tweak to the *content* of the package, and not just the dependency
information of a package.  Thus, if you want to take a package and put
it into a different distribution, you may as well make a new package.



On a smaller notes:

>> - Using operators and boolean algebra makes the dependencies hard to
read, hard to get right and hard to analyze.

This is not true for those who have tried it.  Normally you don't use a
version dependency at all.  Even when you do, you usually say simply
"version >= 3.2".  It's not hard in practice.

Also, by the way, increments in the major version are usually treated as
creating new packages.  Thus you depend on things like "foolib3" instead
of just "foolib".  This trick gets rid of the most common needs for
version dependencies.


>> - It there is a conflict Debian can only barf at you and you essentially
>> have no good options. Sure, it doesn't happen often, but Debian is more
>> coarse grained and Debian can pretty easily have coexisting libraries
>> etc.

This isn't a lovely situation, but how can you really solve it?  How is
it different from any other bug?

There are two major answers to this kind of problem:

	1. Stick with tested releases that have been verified to have no
conflicts or major bugs.

	2. Live with it, and try to get problems fixed as quickly as possible.

This is exactly what Debian does (sorry to harp, but Debian has the same
issues at this level!).  They have "stable" and "unstable" releases
corresponding exactly to these situations.



Finally, on a bigger note, what do you suggest for packages that want,
say, any mail-sending utility and don't care which one?  You say you
don't like dependencies such as "web-server" or "smtp-client".  What is
to be done instead?  The smtp-client dependency is already happening in
Squeak.


Lex