Hi Goran,


> That is exactly the difference. There can be multiple package
> configurations associated with a package. AND even more importantly -
> the package configs are *associated* with the package but *owned* by 
> the
> person registering them. This means that *I* can publish a working
> config for *your* package.
>
I agree, that this is good to have.
> Another BIG advantage of having the dependencies outside the package
> releases is that if I need to change the dependencies - I *do not* need
> to publish a new release.
not of the package, but of the config.

>> The package should know what it needs.
>
> No, :-) I don't agree. A very important aspect is that the packages
> should NOT know what they need.
> Because they may be wrong. Or put another way, the author of a package
> has his/her idea of what the package needs - but I may know of
> alternatives. There may be several configurations for using say
> HttpView. I know a few, but you may know of even more.
Ahm, I agree that the package should not _always_ automatically load
a prerequisite according to above reasons, but if I could overwrite the
version of some prereq it needs, why shouldn't it load some default
prereqs? If the above is the only reason, why a package should not
know its prereqs _at all_, I disagree.

I think there should be both, external configs, which could overwrite 
some
internal defaults. What do you think?

Markus