Hi all, [...] > > 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. > Propositional logic doesn't have too many corner cases. The problem is simply that people don't even get current Depends right, introducing additional expressiveness will worsen the situation. > > (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 > Correct NNF rewrite, but the first expression is wrong already. Sort of confirms my above statement. All you say with this is expression is one case you don't want to occur (it's the "If you try to install A and B in one go, C(A) will go in as well." case). It would, however, be satisfied by installing C only, or B and C for that matter. > 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. > I'm still wondering why people are so hesitant to write proper Depends: lines. I'll reply to Harri's email to reiterate that. Best, Michael
Attachment:
pgpN26YfD51wR.pgp
Description: PGP signature