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

Reply via email to