[pacman-dev] AUR pacman package fixes bug 9395 - comments?
bji-keyword-pacman.3644cb at www.ischo.com
Tue Dec 30 18:22:40 EST 2008
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
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
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
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:
Thanks, and best wishes,
More information about the pacman-dev