On 2019-02-08 00:58, Francesco Poli wrote: > On Wed, 6 Feb 2019 23:44:43 -0500 Boruch Baum wrote: > > > 2) My druthers would be for option 'a' to be made an upper-case 'I' and > > the unqualified option 'p' be made an upper-case 'P'. > > Which would be the advantage of this renaming? > I mean, apart from pleasing personal tastes (which are different for > distinct people, as is well known).
It was one of several in the proposal to make it easier to remember what each letter does. 'a' is 'ignore all' and 'i' is ignore one. Since there could be many operations that operate on 'all', I suggested a convention where a lower-case letter operates on a single item (or an explicit list of items), and the same letter in upper-case performs the operation on all. > > > > > 3) If there already exists an option 'n' that can stop the APT > > installation, why can't an unqualified 'p' option do the same? > > If I understand correctly, you are saying that 'p' could pin all the > packages and stop the APT installation immediately after. > > > What > > further operation are you expecting a user to do after 'p'? > > After pinning all the packages, the user may for instance still want to > query some bug numbers, or mark some bug numbers as ignored. Okay, as an alternative, if you're willing to revisit consideration of changing 'a' to 'I', as above, then 'a' could be 'abort'. > The pin operation is performed on packages, not bugs. > This is because the pinning in APT refers to packages: the annotated > list of bugs that convinced the user to pin a package is just a comment > for apt-listbugs (the cron job of which will take those bugs into > account). I sense a subtle distinction; correct me if I'm wrong: apt pins on packages, but apt-listbugs pins on bugs, correct? That's what the comments in the pin file are for, to track when to remove the apt pin, yes/no? > If you want to pin a package affected by n bugs, but you only fear a > subset of the n bugs, you may: > ... Thus my suggestion to explicitly allow pinning by bug, using a form `p <arg>', where arg could be an entry number, a bug number, or a package name. This would be in practice quite useful in situations where an apt upgrade is installing many packages with many apt-listbug entries, to save the sysadmin from needing to jot down somewhere the list of bugs to comment out before aborting and re-starting the upgrade. > Do you mean there's no 'i' option without arguments? > This can be considered intentional: marking bugs as ignored should not > be too recommended, in my humble opinion, hence I don't want to > encourage users to blindly mark a bunch of bugs as ignored... But that's what the current option 'a' does! I just proposed changing the mnemonic to 'I'. I edited the following to change 'n' to 'a' for abort ... Hmmm, you know what, let's also change 'y' to 'c' for continue ... > > 7) So your simple request did eventually get me here, with the following > > for the extended prompt, which definitely pre-supposes changes to > > option keys and functionality: > > | How to deal with the listed bugs [y|n|P|I|U|R|r|w|#..|p..|i..|u..|?]?" Y | | c - continue the install. Do not mark the bugs 'ignored'. | a - abort the APT installation. | P - pin all the listed bugs, and stop the APT install | I - continue the install. Mark the bugs 'ignored'. | U - remove all pins and ignore states. | r - redisplay the bug list | R - redisplay the bug list, with ALL pins and 'ignored' bugs. | w - redisplay the bug list in HTML | ? - redisplay this help. | | In the following options <arg> may be an entry b<num>, a | debian bug number <num> or #<num>, or a package names. <args> | may be a list of those, in any combination. | | <arg> - display bug detail, using querybts | p <args> - pin pkgs (Later, you must select 'n' to enable this). | i <args> - ignore bugs on future APT runs. | u <args> - remove pin and 'ignore' states > > Really complicated, but the suggestion to implement an undo command is > something I am going to think about. It's different, but try it out on a few people. Lower case to perform a command on a single <arg> or an explicit list of <arg>, and upper case to perform an operation on all. Then the interface is consistent and the mnemonic is [p]in, [i]gnore, [u]ndo, [r]edisplay (maybe redisplay should be [l]ist? C-g for emacs users?). The outliers are [c]ontinue, [a]bort, and [w] for HTML redisplay (I don't want to get involved...) The letter-choices I can live with no matter what you decide, but I think my proposal is an improvement. More important is the undo idea, and most important from my perspective is to dump into the apt pin file only those individual bugs for a package that worries the user, ie. not belabor the user to remember the bugs to remove from the pin file comments. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0