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

[Allan McRae]

Bryan Ischo wrote:
> 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

As I expected, that package has already been deleted from the AUR.  
Submit your patch for the code here.  You don't need to update the NEWS, 
configure.ac files etc because the will be done by us at release time.

Allan