On 19 January 2011 22:23, Stéphane Gaudreault <steph...@archlinux.org> wrote: > As the maintainer of A, it is not your job to track dependencies of B and D. > > Again, look at the problem from a different point of view. If tomorrow > dependencies of B change to > > B -> C F (direct dependecies) > > does it mean that A (and **all** other pkgs that depends on B) should be > updated to include a dependecy on F ? What if dependency on E is removed from > C PKGBUILD ? Maintaining a package with such rules will be a nightmare.
If A depends on B AND C while B depends on C, then it is correct to list both B and C as dependencies of A. That is as proper as it gets, and this most of us do not practise currently. Aside from any technical disadvantage, it is just clutter to my eyes. It is also correct to list only B as a dependency of A, since B would pull in C, but this correctness is only assumed correctness, provided link-level dependency has not been checked. This, most of us do currently. PKGBUILDs and pacman dependency lists are easy to look at. I don't see a need to 'settle' this one. You may not list glibc because it simply makes no sense to not have it at the time of installation. It can be as far deep down as F, but ultimately it is the packagers' (and community's) responsibility to incorporate dependency changes. As a community, changes like this are hard to miss. C getting out of B's dependency chain does not happen a lot. When it does, someone can report it. So we (should) stick to the simple(r) way - the current way.