[pacman-dev] AUR pacman package fixes bug 9395 - comments?

[Bryan Ischo]

Hi all.  I'm sorry I didn't post to this list earlier about this issue; 
I kind of forgot that there was a pacman-dev list and I added my 
comments to the bug, not realizing that I should post here too.

Anyway, I have created a patch for pacman 3.2.1 which changes the 
behavior of pacman when it encounters unresolvable dependencies during a 
sync.

The current behavior is that any time a package to be upgraded has a 
dependency that cannot be resolved, pacman asks if the user would like 
to ignore the missing dependency and install the package anyway.  If the 
user answers yes, the sync proceeds, resulting in broken dependencies.  
If the user answers no, then the sync fails immediately.

This situation can be quite common if you use the IgnorePkg/IgnoreGroup 
feature, because any package which depends on an upgrade to an ignored 
package cannot be sync'd, and thus the user is forced to ignore more and 
more packages to prevent sync -Su from being impossible to complete.

My patch causes pacman to, instead of issuing a force/fail question when 
an unresolvable dependency is discovered, keep track of which packages 
that it would upgrade cannot be upgraded for this reason, and issue a 
single question to the user at the end of the package resolution step, 
of this form:

:: the following packages cannot be upgraded due to unresolvable 
dependencies:
        package1,
        package2,
        package3,
        etc.

Do you want to skip these packages for this upgrade? [Y/n]

If the user answers yes, then the offending packages will simply be 
removed from the sync operation and the remainder of the sync can occur 
as normal.  If the user answers no, then the sync cannot proceed, and it 
fails.

So this changes the "force/fail" question into a "skip/fail" question, 
which I think is better.  In fact, I can't think of any disadvantages to 
doing it this way - can you?

I don't have a patch to submit for this; instead I've created a patch as 
part of an AUR submission that produces a new version of pacman with the 
behavior I have described.  I think this is an easier way for users to 
test this feature.  But I would be more than happy to submit a patch to 
this list directly for this issue if it is the preferred means of 
getting this change into the official pacman sources.  A question I have 
though, is exactly what should be patched?  The NEWS file, configure.ac, 
etc?  Or just the code?  I ask because my patch introduces what I 
believe to be an incompatibility in libalpm with the previous version 
(because a new "question" has been added, that amounts to an addition to 
the API), which requires a new libalpm version number, so there are lots 
of files in the pacman source that need to be patched to effect this.  
Should I submit a patch to this list that takes pacman-3.2.1 to 
pacman-3.3.0 (with libalpm 4.0)?  Or should I just submit the actual 
header and source file changes (plus man page and other documentation 
changes, I am sure) in a patch to this list?

Any questions, concerns, comments, or other feedback about this patch 
would be most appreciated.

The bug in question is at:   http://bugs.archlinux.org/task/9395
The AUR package that I have created is at:   
http://aur.archlinux.org/packages.php?ID=11182

Thanks, and best wishes,
Bryan