FS#7622 - pacman stuck in infinite loop

Attached to Project: Pacman
Opened by Scott H (stonecrest) - Monday, 16 July 2007, 05:54 GMT
Last edited by Dan McGee (toofishes) - Thursday, 15 November 2007, 06:08 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.0.5
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

If I run pacman -Rsc libcups, I get a line that is printed out indefinitely.

$ pacman --debug=1 -Rsc libcups
<snip>
debug: checkdeps: found pidgin-mtn as required by gtkspell
error: could not find pidgin-mtn in database -- skipping
debug: checkdeps: found pidgin-mtn as required by gtkspell
error: could not find pidgin-mtn in database -- skipping
<snip>

And so it goes..

Upon talking with Dan, I didn't have a pidgin-mnt dir in my local DB but it was in another gtkspell's REQUIREDBY. If nothing else, it would be nice if pacman handled this more elegantly so that it doesn't simply get stuck in an infinite loop - perhaps by simply removing the stale entry in the DB.
This task depends upon

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Dan McGee (toofishes)
Thursday, 15 November 2007, 06:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in GIT as stated in the comments. In addition, we no longer have explicit storage of requiredby, so this shouldn't ever happen again.
Comment by Xavier (shining) - Monday, 16 July 2007, 09:13 GMT
By reading the code, I would say this has already been fixed in 3.1 by Nagy's work on the remove part of checkdeps() :
http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=796cc4e6ed06644081f05c1aff4624a6e11eade3

+ if((p = _alpm_db_get_pkgfromcache(db, j->data)) == NULL) {
+ /* hmmm... package isn't installed... */
+ continue;
}

See here, if a package doesn't exist, checkdeps won't add it to the list, and so the code in remove.c won't loop.
The part printing the above message "error: could not find pidgin-mtn in database -- skipping" will never be reached actually :p

I was thinking that maybe pacman could have an option for detecting the broken requiredby fields, and maybe also repair them?
http://www.archlinux.org/pipermail/pacman-dev/2007-July/008917.html
Comment by Xavier (shining) - Monday, 16 July 2007, 09:32 GMT
attached a pactest if you still want one :)
loops with pacman 3.0.5 , works nice with pacman git.
   0001-Add-remove046-pactest-fo... (0.8 KiB)
Comment by Scott H (stonecrest) - Monday, 16 July 2007, 14:53 GMT
I was thinking about this some more, and I think that simply skipping these packages is probably the more conservative thing to do. If pacman ever got to this code and, for some strange reason, the DB no longer existed, you'd end up removing every single requiredby field of every package. I'm obviously saying this without having strong knowledge of the code, so I don't know if this scenario is at all possible, but it seems that the current implementation that exists is less risky.
Comment by Xavier (shining) - Monday, 16 July 2007, 15:04 GMT
It would be weird that the DB no longer existed, yet still being able to write on it. But I guess this could be possible with some weird bugs in the code.
So yep, it might be safer to not automatically try to repair these during a transaction.
But maybe a dedicated pacman option or a little external tool for repairing could be better.
Comment by Dan McGee (toofishes) - Wednesday, 14 November 2007, 22:57 GMT
If we push my requiredby changes, I feel like this bug is no longer valid, even though we have already found it to be "fixed" in pacman GIT. Maybe another reason we should get rid of requiredby.

Loading...