[aur-general] [arch-general] Please settle 'base' in 'depends' for all
schiv at archlinux.org
Wed Jan 19 10:19:49 EST 2011
On 19 January 2011 22:23, Stéphane Gaudreault <stephane at 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.
More information about the aur-general