Arch Linux

I don't think there is anything wrong here. Just don't update obconf in the first place. (maybe ignore it too).

In this specific case, it might be possible to remove obconf from the targets. But suppose that the other targets
depend directly or indirectly on that obconf version. Then what? You also skip all these targets?
Might as well just cancel the whole transaction as it does now.

obconf updates automatically with the sysupgrade. Naturally, adding obconf to the ignore list would work.
In my opinion it would seem reasonable to drop all conflicting packages from that upgrade which depends on another packet currently not selected for upgrade (ignored).
This way the system can still stay up to date, except for conflicting packages which are ignored rather causing pacman to disbehave.

"Then what? You also skip all these targets?"
Imho he wants this, which can be reasonable in case of sysupgrade.

This is the analogue of my -Ru patch; we can "resolve" dependencies by adding more targets to the target list (resolvedeps, -Rc) or by removing targets from the target list (toxic's request, -Ru).

This is not hard to implement at all, the question is, how this should work (first add method, then fallback to target remove (optional) seems acceptable to me). The only question is that we need this feature or not.

Naturally, there's no great severity in this matter since it can be resolved by adding conflicting package to the ignore list. Despite this, for the in-experienced user
who might need som updates (say new antivirus definitions or a pdf-reader for tomorrows presentation) where one conflicting packet should not stall those others that can
be applied cleanly. Well, enough with the ranting. To me, it does make sence to simply notify the user, "the following packets .... and it's dependencies ..." failed and
then continue with updating the other packets.

Still, in the end the user must deal with the problem, but more so at a time of his/her choice.
I don't think pacmans force option could be applied either, as it to my best knowledge would install the conflicting packet despite dependency checks, thereby breaking the
depency cycle. I could probably have submitted the code myself where it not for the fact that I'm no arch-developer :P


To answer the question if we need it or not. It would be nice, no extra or complex pacman options would be added, likely not too much code overhead; and all to give the user a chance to work
with pacman in this aspect without "immediate" manual intervention. On the other hand this is less likely to happen if the system is maintained on a weekly basis.

I agree with johan that this would be a desirable feature of pacman. As it stands, it doesn't seem to me that the "IgnorePkg" feature of pacman is really workable with the current behavior, because it requires the administrator to manually manage a growing list of packages in the IgnorePkg list. I can't see any downside to allowing sync transactions to proceed by eliminating any package that the user answered 'no' to in the 'this package depends on a package which is not being upgraded, do you still want to upgrade this package' question, rather than failing the transaction completely. The example I use is this:

* firefox depends on xulrunner
* If I add xulrunner to my IgnorePkg, and xulrunner and firefox have new versions, then pacman -Su will ask me this:

:: firefox requires installing xulrunner from IgnorePkg/IgnoreGroup. Install anyway? [Y/n]

If I answer yes, then I'll end up with a firefox that has broken dependencies. If I answer no, the upgrade aborts with:

error: cannot resolve "xulrunner=1.9.0.5", a dependency of "firefox"
error: failed to prepare transaction (could not satisfy dependencies)
:: firefox: requires xulrunner=1.9.0.5

* But I didn't say 'no' to the whole transaction, I just said 'no' to the question that was asked of me, about whether or not to upgrade firefox. So why does the whole transaction get aborted?

The obvious workaround is for me to manually add firefox to my IgnorePkg list and proceed with a new sync. But consider a few points:

* This requires manual intervention when the tool could just as easily handle this situation automatically. I would go so far as to say that pacman should not ask if you want to upgrade packages whose dependencies cannot be satisfied; it should drop them from the transaction altogether and issue a warning to the user as it does so, but it shouldn't even interrupt the sync process to ask the user about it.

* What if a future version of firefox no longer depends on xulrunner? I've got firefox in my IgnorePkg list just because it depended on xulrunner, and now I have to manually check to see if this reason continues to be valid for each new version of firefox, because the only reason I put firefox in the list in the first place was because of xulrunner. If a new version of firefox doesn't depend on xulrunner, then obviously I don't want it in my IgnorePkg list any more. This is more manual management of the process that is unnecessary.

I am somewhat new to Arch so I may be missing important points, and would be happy to be educated as to why what I propose is not a good idea. But assuming that it is, I would like to see:

* pacman -Qu show all packages that have upgrades available even for packages which are in my IgnorePkg list (or dependent on these), as it does now, but with an asterisk next to the package name so that I can tell that this package would in fact not be upgraded due to IgnorePkg configuration, even though an update is available. In this way I can easily tell when I'm 'behind' on packages just because I've got things in my IgnorePkg list, and decide whether or not I want to revisit my reasons for having these packages on the IgnorePkg list.

* pacman -Su should automatically cull out the packages on my IgnorePkg list as well as all packages which depend on these packages, and should (possibly) issue warnings about the packages that it ignored.

I can't see any downside to either of these changes. I believe that they are strongly in the KISS spirit, as they keep package management for users simpler than the manual process of managing a complex IgnorePkg list (the difference being, only having to put in the packages that you really want to ignore in IgnorePkg, not also having to keep track of dependencies on these packages and put the dependent packages in the list as well, as is currently the case). They do make the pacman or libalpm code slightly more complex, but I think this is well worth it.

I would be happy to submit a patch for these changes if Arch developers would like me to.

Hello, I have submitted a version of pacman to the AUR which fixes this bug. Would the pacman maintainer(s) please take a look at my package, and the patch it includes, and give feedback? The package is at:

http://aur.archlinux.org/packages.php?ID=11182

(it is called pacman 3.2.1FIXBUG9395-1)

Some comments:

- I tried hard to obey the coding conventions for pacman, however, I cannot promise that it's all 100% coding convention compliant. If you find changes I have made that are not coding convention compliant, please let me know.

- I created a new structure, defined and used only internally in lib/libalpm/deps.c, called pkginfo_t. This structure just provides some bookkeeping information about packages as they are being resolved, including whether or not the package was "pulled", whether or not the package is "unresolvable" (meaning, it depends directly or indirectly on a package which could not be resolved, typically due to being in IgnorePkg/IgnoreGroup), and the list of dependent packages for each package (i.e. the packages which depend on *this package*, not the packages that *this package* depends on).

- The algorithm is basically to, every time a dependency of a package cannot be resolved, mark that package and all packages which depend on it as unresolvable, rather than immediately asking the user whether or not to force the upgrade of that package or fail. At the end, the set of packages which were not "pulled" and yet were unresolvable is determined, and if this is not an empty set, a new question is asked of the user: whether they want to remove those packages from the transaction. If they do, then all unresolvable packages (and all resolvable packages that were only added to the transaction in order to satisfy dependencies of unresolvable packages) are removed from the transaction, and the transaction proceeds. If they do not, then an error is returned from the function, just as it had been previously if the user had decided not to force the update.

- The new question I added to libalpm is an API change that requires an update to the major version of libalpm, so I bumpted it to version 4.0. Note that any other package managers which depend on libalpm will have to be updated in order to be used with this package.

- I added a new pacman.conf option called NoIgnorePrompt, with a corresponding pacman command line option of --noignoreprompt, which prevents pacman from asking the user whether or not they want to upgrade a package that is in their IgnorePkg/IgnoreGroup list. I personally find those prompts unnecessary - why ask me whether or not I really don't want to upgrade the package? I put the package in my IgnorePkg list specifically because I didn't want to upgrade it, so I find this question to be redundant. However, others may like/depend on it, so removing this question is a new option that defaults to the old behavior.

- I am not sure if package version 3.2.1FIXBUG9395 is really kosher; it seems to act like an "older" version that pacman 3.2.1 rather than a "newer" version, which causes pacman to ask if the user would like to upgrade pacman to 3.2.1 each time pacman 3.2.1FIXBUG9395 is fixed, but I didn't manage to find a better way to give this pacman package a unique and descriptive name without bumping the minor version number up.

- I did not modify pacman -Qu to show ignored packages (and their dependents) with an asterisk as I had suggested previously, because that would require doing a resolve during query, which I don't think pacman does now, and is not something I wanted to make it do.

- I tested my change on all of the scenarios that I could imagine, but it definitely needs to be banged on by alot of people for alot of upgrades before I will be confident that it is bug-free.

- It took quite a few hours to produce this, so I hope that the pacman mantainer(s) can help see my effort through to incorporating this functionality in pacman 3.3.0 - thank you!

Here is a sample session of using pacman -Su with my changes, and with some packages in IgnorePkg that cause pacman to have to dump some packages from the transaction:

[code]
<pre>

[root@lolita ~]# pacman --version

.--. Pacman v3.2.1FIXBUG9395 - libalpm v4.0.0
/ _.-' .-. .-. .-. Copyright (C) 2006-2008 Dan McGee <dan@archlinux.org>
\ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet <jvinet@zeroflux.org>
'--'
This program may be freely redistributed under
the terms of the GNU General Public License.

[root@lolita ~]# grep IgnorePkg /etc/pacman.conf
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
IgnorePkg = kernel26 pango tdb
[root@lolita ~]# pacman -Su
:: The following packages should be upgraded first :
pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n] n

:: Starting full system upgrade...
warning: kernel26: ignoring package upgrade (2.6.27.8-1 => 2.6.27.10-1)
warning: pango: ignoring package upgrade (1.22.3-2 => 1.22.4-1)
warning: tdb: ignoring package upgrade (3.2.5-1 => 3.2.6-2)
resolving dependencies...
:: the following packages cannot be upgraded due to unresolvable dependencies:
firefox,
gtk2,
smbclient,
xulrunner

Do you want to skip these packages for this upgrade? [Y/n]
looking for inter-conflicts...

Targets (29): openssl-0.9.8i-3 ca-certificates-20080809-5 libpng-1.2.34-1
xcb-util-0.3.2-1 cairo-1.8.6-1 dbus-glib-0.78-1
diffutils-2.8.1-6 libtasn1-1.7-1 gnutls-2.6.3-1
hal-info-0.20081219-1 hdparm-9.3-1 hwdetect-2008.12-3
intel-dri-7.2-2 klibc-udev-135-1 libdmx-1.0.2-2
libxml2-2.7.2-1 libgsf-1.14.10-1 libxfont-1.3.4-1
nss-3.12.2-1 pacman-3.2.1-2 pycairo-1.8.0-1
subversion-1.5.5-1 sudo-1.7.0-1 tar-1.20-3 ttf-dejavu-2.28-1
udev-135-1 xextproto-7.0.4-1 xkeyboard-config-1.4-2
xorg-font-utils-7.4-1

Total Download Size: 23.64 MB
Total Installed Size: 80.21 MB

Proceed with installation? [Y/n] n
</pre>
[/code]

It seems to me like an excellent patch, and the best method to deal with the problem.

Changes have been submitted to the official pacman git repository that fix this bug. These changes will be included in the 3.3 release of pacman.

The new behavior for pacman will be to prompt the user interactively if unresolvable packages were discovered during a sync operation, asking whether to ignore those packages and continue, or fail the sync immediately with error. The default choice is the former.

The git ids of the changes are:

6c4d702cb10f9bc5da23b6511f09f4b4a07a4281
02685504012a4880e599b15f1060f6bd0bf48797
f57f8d33862050acc8d131710c100ba47877e675