On Sat, Aug 20, 2011 at 07:55:10AM +0100, Michael Tautschnig wrote: > Hi Harri, > > > would it be possible to support combined dependencies, > > e.g. if package A and B are installed, then package C(A) > > has to be installed, too? > > > > That might be helpful for dkms packages, for example. > > A would be the kernel, B the dkms package, and C(A) > > would be the headers for A. > > What event would induce installation of C(A)?! Let's assume neither A nor B are > installed. > > apt-get install A > (no point installing C(A)) > apt-get install B > (B does not depend on C(A), otherwise this discussion is pointless) > > ... time passes ... > > magic install C(A) > ??? No, you can't install B without C(A) if A is installed, that's the whole point of conditional dependencies. Thus at the second command apt would pull in C(A) or throw an error if it's uninstallable. If A is installed, B gains Depends:C(A). If B is installed, A effectively gains Depends:C(A). If you try to install A and B in one go, C(A) will go in as well. If you try to uninstall C(A), either A or B has to be uninstalled. The semantics are pretty obvious to me, it's the number of corner cases and complexity that this brings what stops dpkg/apt/aptitude/100-other-tools maintainers from implementing that. (Let's rename "C(A)" to "C" for now, the former name makes no sense except when talking about dkms.) Logically, what you want is: !(A & B & !C) This is: C | !A | !B Technically, you could already get this effect by introducing a dummy package no-B that "Breaks: B" and having A "Depend: C | no-B". In the case of dkms, there's one dkms and many kernels so B=dkms, A=kernels. Too bad, linux-image-$FOO depending on linux-headers-$FOO|no-dkms would be too ugly to live. Just think of confusing messages from apt... This could be done by no-B being a new kind of a virtual package, but I for one don't volunteer to code that. -- 1KB // Yo momma uses IPv4!
Attachment:
signature.asc
Description: Digital signature