> Not true.  The dependancy graph should be like a tree.  With
> dependancies going down and sideways only.  Ie, KDE can obly
> depend on a package either A) supplied by a sibling repository
> or B) supplied by the base repository.

That's what he said. The twist he added is that different
repositories may demand different versions of their
dependendencies in a shared parent repository. And then, indeed,
he's hosed.
Ah but the point is that if they both use the same base repository they wouldn't have version conflicts as there should only be one version of a dependency in the base repository.  If the app required a different version of a dependent package than was in the base repository then the child repository would supply it in a way suitable for installation along side the other version.   Or the base repository could also supply this dependency.  This technique is used quite a bit these days. 

eg:

[oliver] luna:~$ rpm -qa |sort|grep autoconf
autoconf213-2.13-6
autoconf-2.57-3

[oliver] luna:~$ rpm -qa |grep libgal |sort
libgal21-0.23-1
libgal2-1.99.10-2
libgal23-0.24-2

His example wasn't a problem that couldn't be addressed easily given the appropriate packaging structure. 

Though I do think that giving packages names with version numbers is a little naff.  I would prefer for the same named rpms to just be installed side by side.  Which you can do fine as long as there are no file conflicts in the package.  Which is why you can easily install multiple kernel and kernel-source rpms on a box.

eg:

[oliver] luna:~$ rpm -qa |grep kernel|sort
kernel-2.4.20-27.9
kernel-2.4.20-28.9
kernel-2.4.20-30.9
kernel-2.4.22-1.2115.nptl
kernel-2.4.22-1.2174.nptl

Regards 




-- 











Oliver Jones » Director » oliver.jones@deeperdesign.com » +64 (21) 41 2238 

Deeper Design Limited » +64 (7) 377 3328 » www.deeperdesign.com