I just found a funny test case on my first try. Funny because besides the same missing dependency message being printed many times, there is also a "provider package was selected" printed multiple times, which makes the whole thing worse. If I understood you correctly, all these missing dependency messages look the same because we are missing one information : the "causingpkg", which is a target package that has an unresolvable dependency, correct?
Yes.
So with that additional info, all these missing dependency messages would be different. It seems fine to me to reuse the causingpkg field for that, because that name is quite general. We would just need to document well what it means in -R case, and what it means in -S/-U case.
sudo LANG=C pacman -S kde --ignore libxinerama kde package not found, searching for group... :: group kde (including ignored packages): kdeaccessibility kdeadmin kdeartwork kdebase kdebase-runtime kdebase-workspace kdeedu kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdepim kdepimlibs kdeplasma-addons kdesdk kdetoys kdeutils kdewebdev :: Install whole content? [Y/n] resolving dependencies... warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" warning: cannot resolve "libxinerama", a dependency of "qt" warning: cannot resolve "libxinerama", a dependency of "qt" warning: provider package was selected (freeglut provides glut) warning: cannot resolve "libxinerama", a dependency of "qt" :: the following package(s) cannot be upgraded due to unresolvable dependencies: kdeaccessibility kdeadmin kdeartwork kdebase kdebase-runtime kdebase-workspace kdeedu kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdepim kdepimlibs kdeplasma-addons kdesdk kdetoys kdeutils kdewebdev
Do you want to skip the above package(s) for this upgrade? [Y/n] looking for inter-conflicts... local database is up to date
Wow, this is weird. And now I am a bit unsure about my "warning: ignoring foo..." patch. :) By the way, I don't think those "warning: cannot resolve libxinerama" messages are useful, these kind of infos should be collected "at the end" (using *data list or whatever). In fact, now the "provider package was selected" can be false, because we may finally remove that package (freeglut) from the target list. So that message should be completely removed imho. (However, that message was introduced when I switched to _alpm_resolvedep usage in sync_addtarget... Now I am not sure that was a good idea, see its prompt param. But if we keep this resolvedep stuff, we can detect providers comparing depend->name and target->name in sync_addtarget.) The main problem is (which was predicted in Bryan's first "Another idea" mail), that resolvedeps want to resolve the same dependency path many times (which is slower), which is not successful here... Bye