On Wed, Sep 26, 2012 at 2:25 PM, Stefano Zacchiroli <zack@debian.org> wrote: > [ Re-posting this as APT bug report, to keep track of it. The original > version is at https://lists.debian.org/deity/2012/09/msg00088.html , > the thread with further discussion (and in particular the POV of one > of the Policy Editors) at > https://lists.debian.org/deity/2012/09/msg00088.html ] Thanks for making a report out of it. I made a patch for this already as I agree with Russ (and dpkg) here even though I have a hard time comeing up with a good example why. Attached (this time I made sure it really is…) and planed for 0.9.7.6. It painfully shows that I made a mistake in not keeping track of the types of a dependency (aka: explicit/implicit against all archs/one arch) I guess I have to correct this for Jessie … Anyway: All APT front-ends need to be checked though as the dependency itself exists, so if they check dependencies themselves they need to be told to ignore them, too. As you can see in the patch libapt provides a method for that, but the method is relatively new and the previous check for self- conflicts so simple that it could easily be done on your own. (There is a similar one for Provides, which isn't that trivial in M-A either, so we might want to check for this, too) There shouldn't be that many clients implementing their own dependency checking though - likely at most those with own solver implementations. Hence cc'ing the aptitude deities so they can have an early look at that. Best regards David Kalnischkies
Attachment:
apt-688863-self-conflicts-for-real-same-package.diff
Description: Binary data