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(a)deeperdesign.com » +64 (21) 41 2238 Deeper Design Limited » +64 (7) 377 3328 » www.deeperdesign.com