Cédric Girard wrote:
It means then that if we have this (dependency are direct dependencies): - Package A: depends=(B C) - Package B: depends=(C)
C should *not* be removed from the dependency array of A.
I agree with this. A package should list as its dependencies any package on which it directly depends, and only those packages. There is no need to create a "core" group for dependency resolution, e.g. one that would include the kernel and other necessary packages for a minimal system.* Those aren't direct dependencies, as the chroot example shows. Of course, any package that e.g. requires kernel headers should to list linux-api-headers as a dep, even if it is a dep of glibc and generally assumed to be on the system. The argument that some packages are guaranteed to be on the system and thus checking for them is just a waste of time is a bad one. Checking assures correctness of the dependency graph, and the overhead is negligible because if the package is installed, as it almost always will be, then all pacman has to do is check that the package is listed in the local db, which probably amounts to testing for membership in an internal hash or list of less than 1000 members. If everyone were to use implicit dependencies then pacman would fail because no package would specify the required dependency. A rule that would break the system if it were followed by everyone is a bad rule. Expecting some to follow it and others not to and just hoping that everyone will keep working is simply bad practice. It's not minimalist... it's just lazy. * It might be useful to have a group that install a minimalist system and pacman, i.e. the smallest package set that can boot to a prompt and let the user install packages.