On Wed, 6 Feb 2019 23:44:43 -0500 Boruch Baum wrote: > On 2019-02-07 11:25, Stuart Prescott wrote: > > Control: reassign -1 apt-listbugs 0.1.28 > > Control: severity -1 wishlist > > Control: retitle -1 apt-listbugs: simplify wording for pinning description > > > ... > > > I've reassigned this bug to apt-listbugs as that is the appropriate > > package.
Hello Stuart, thanks for reassigning the bug report.
Hello Boruch, thanks for filing it.
Please note that apt-listchanges has little or nothing to do with
apt-listbugs, hence I dropped apt-listchanges@p.d.o from the Cc list...
> > If you can suggest an appropriate improvement to the wording
> > of the above help text then that would be useful.
>
> Well, since you asked ...
Dear Boruch, as the maintainer of apt-listbugs, I will try my best to
reply to your questions/doubts and to analyze your proposals.
>
> 1) Maybe for the user prompt, adopt the style of 'reportbug'; something
> like:
>
> How to deal with the listed bugs [y|n|a|#..|p..|i..|w|?]?" Y
>
> This intentionally breaks the convention of upper-casing the default,
> since the default is written anyway, and because ...
Mmmh, reportbug does seem to follow the "default in upper-case"
convention, though.
For instance, it asks:
(5-13/13) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]?
On the other hand, listing all the possible answers between brackets
looks a bit hard to read (especially if the line becomes longer than
the terminal width, which may happen in some non-English language
localization...).
I am not especially enthusiastic about this proposal.
>
> 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).
>
> 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.
> Requiring
> an extra manual step introduces an unnecessary opportunity for
> user-error, and introduces confusion of when and how to perform the
> abort.
It's true that an extra command is needed, but it's there to give the
user the opportunity to perform other operations (as explained above),
before exiting.
>
> 4) The extended prompt, and the man page documentation, make it seem
> like pinning is done for all or none of a package's listed bugs; it's
> unclear whether in a case of two or more bugs being listed for a
> single package, if its possible to pin only a sub-set of the bug
> list, eg. 'p <num>' or 'p b<id>'.
Why do you say it's unclear.
Where did you get the impression that 'p <num>' or 'p b<id>' exist?
The man page does mention them and explicitly says:
[...]
| if any such bug is found,
| apt-listbugs warns the user and asks how to proceed. Among other
| things, the user has the opportunity to continue, to abort the instal‐
| lation or upgrade, or to pin some packages (so that the unsafe instal‐
| lation or upgrade is deferred). However, pinning is not effective imme‐
| diately, and requires restarting the APT session (by aborting and then
| re-running the same APT command).
[...]
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).
If you want to pin a package affected by n bugs, but you only fear a
subset of the n bugs, you may:
a) manually edit /etc/apt/preferences.d/apt-listbugs and
delete Explanation lines which refer to the bugs you do not fear
or
b) mark the bugs you do not fear as ignored
Personally, I would go with strategy a), since I (almost) never mark
bugs as ignored, but your tastes may be different...
>
> 5) The 'p' option seems to be able to handle a list of packages, which
> is a nice convenience, but the parallel option 'i' isn't annotated
> that way.
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...
>
> 6) There doesn't seem to be a command-line method to recover from a
> keying error or a decision-change regarding pinning or ignoring a bug
> - something like a 'u' option to undo a particular change, and a 'U'
> option to undo all changes. For those options to be practical, it
> would be useful to have yet another option 'R' to redisplay all bugs,
> including those prior marked 'ignored' or 'pinned'.
An undo command could be useful, indeed.
Currently you have to manually edit text files to do that, which I
admit is not especially user-friendly.
I'll have to think about implementing an undo command, hoping that it
doesn't require too heavy modifications to the current implementation...
>
> 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
> |
> | y - install anyway. Do not mark the bugs 'ignored'.
> | n - stop 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.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpa3hT102dOm.pgp
Description: PGP signature
