Summary: | emerge --ask --depclean exits with status 1 when the user says no | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Kevin Lyles <kevinlyles> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | Normal | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=887817 https://bugs.gentoo.org/show_bug.cgi?id=688052 https://bugs.gentoo.org/show_bug.cgi?id=917120 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 406323 | ||
Bug Blocks: | 409383 |
Description
Kevin Lyles
2012-03-25 15:18:06 UTC
(In reply to comment #0) > If there is actually a problem with depclean, I may miss it > unless I watch the script very closely. You could run it once with --pretend, and then have your script prompt the user. Alternatively, you could intercept the user's y/n answer and feed it to emerge (though you'd have to use a pty since --ask only works with a tty device). (In reply to comment #1) > (In reply to comment #0) > > If there is actually a problem with depclean, I may miss it > > unless I watch the script very closely. > > You could run it once with --pretend, and then have your script prompt the > user. Alternatively, you could intercept the user's y/n answer and feed it > to emerge (though you'd have to use a pty since --ask only works with a tty > device). I prefer not running the depclean dependency calculations twice, but it is an option. From the other bug, it looks like 0 or 1 were the only options considered. Can we return 2 or some higher value instead if the user cancels (in both cases)? I can see the argument for not returning 0, but it seems odd to have an intentional abort look the same as an error. Since a 'no' answer is roughly equivalent to interruption by SIGINT, we could return 130 = 128 + signal.SIGINT. (In reply to comment #3) > Since a 'no' answer is roughly equivalent to interruption by SIGINT, we > could return 130 = 128 + signal.SIGINT. Sounds good to me. This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ac13a18708d6223accb85d12ba895bc121df89c6 (In reply to comment #5) > This is fixed in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=ac13a18708d6223accb85d12ba895bc121df89c6 I see 130 when saying no in a normal emerge --ask, but not when running emerge --ask --depclean: # emerge --ask --depclean * Always study the list of packages to be cleaned for any obvious * mistakes. Packages that are part of the world set will always * be kept. They can be manually added to this set with * `emerge --noreplace <atom>`. Packages that are listed in * package.provided (see portage(5)) will be removed by * depclean, even if they are part of the world set. * * As a safety measure, depclean will not remove any packages * unless *all* required dependencies have been resolved. As a * consequence, it is often necessary to run `emerge --update * --newuse --deep @world` prior to depclean. Calculating dependencies... done! >>> Calculating removal order... >>> These are the packages that would be unmerged: sys-kernel/vanilla-sources selected: 3.2.9 protected: none omitted: none All selected packages: sys-kernel/vanilla-sources-3.2.9 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. Would you like to unmerge these packages? [Yes/No] no Quitting. Packages installed: 1108 Packages in world: 152 Packages in system: 42 Required packages: 1104 Number to remove: 4 # echo $? 1 # emerge --ask portage These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD ] sys-apps/portage-2.1.10.49 [9999] LINGUAS="-pl%" Would you like to merge these packages? [Yes/No] no Quitting. # echo $? 130 # It looks like the culprit may be in unmerge.py, line 538: 530 if "--ask" in myopts: 531 if userquery("Would you like to unmerge these packages?", 532 enter_invalid) == "No": 533 # enter pretend mode for correct formatting of results 534 myopts["--pretend"] = True 535 print() 536 print("Quitting.") 537 print() 538 return 0 It could be in the caller of that code, as well, but I don't know the portage code well enough to track that down quickly. Ok, this should fix it for unmerge actions, including --depclean: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=774f387710bfcd14ffb270375bce3b310c2609ee (In reply to comment #7) > Ok, this should fix it for unmerge actions, including --depclean: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=774f387710bfcd14ffb270375bce3b310c2609ee That commit was buggy. Use this instead: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4e2abb474f0fc624c51948f0939e3123f6382992 (In reply to comment #8) > (In reply to comment #7) > > Ok, this should fix it for unmerge actions, including --depclean: > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > > h=774f387710bfcd14ffb270375bce3b310c2609ee > > That commit was buggy. Use this instead: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=4e2abb474f0fc624c51948f0939e3123f6382992 Looks good. Thanks! This is fixed in 2.1.10.52 and 2.2.0_alpha96. This breaks scripts running emerge in a loop, for example to have a file containing a list of packages to rebuild one-by-one. If I answer "no", I want to skip to the next package. If I hit ^C, I want to quit. I have no way of differentiating between these two now. Can we use a different error code? (In reply to comment #11) > This breaks scripts running emerge in a loop, for example to have a file > containing a list of packages to rebuild one-by-one. If I answer "no", I > want to skip to the next package. If I hit ^C, I want to quit. I have no > way of differentiating between these two now. Can we use a different error > code? Can't your script use a sigint trap if it wants to exit when ^C is pressed? Yes. Thanks for the tip. |