On Thu, 7 Feb 2019 21:18:57 -0500 Boruch Baum wrote: > > 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.
I see, but I would like to keep the equivalence between upper and lower case commands... > > > > > > > > > 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'. In normal circumstances, I would rather avoid changing the meaning of a command. Users may be used to type in a command and expect a certain result: the principle of least surprise suggests me to not change that result, unless there is a very good reason to do so. > > > 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? Almost correct. Let's say that pins are on packages (and package managers which support them, take pins into account, when deciding which version of a package is the candidate to be installed or upgraded). On the other hand, apt-listbugs lets the user decide whether a given package should be pinned, depending on which bugs the package could introduce into the system. > That's what the > comments in the pin file are for, to track when to remove the apt pin, > yes/no? The Explanation comments are used to keep track of which were the bugs feared by the user, back when he/she decided to pin a given package. Thus, when the daily cron job checks which pins may be dropped, it knows which bugs should be checked against the package unpinned candidate version (that is to say, the version of the package that would be ready to be installed, if the pin were removed). I hope this clarifies. > > > 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. Well, this could perhaps be implemented, but it looks really non-trivial. Please take into account this (among the other issues): if the user says "p b2", how can apt-listbugs tell whether the user is meaning bug identified by b2 or rather a package named "b2"? I don't know whether I will get around to it. I cannot promise anything... Sorry about that. > > > 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'. It's true that 'a' currently marks all the bugs as ignored. Actually, back in 2009, this was the behavior of 'y'! The 'a' menu command was created as a replacement for the old behavior of 'y'. And 'y' was modified so that it stopped marking bugs as ignored... I think there was a good reason to apply that change. Please take a look at bug [#484408], for further details. [#484408]: <https://bugs.debian.org/484408> Hence, I am not especially fond of the 'a' menu command. Maybe it could be dropped and replaced by a 'i' menu command (without arguments) which marks all bugs as ignored, without immediately exiting... I haven't yet made up my mind, though. [...] > 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, As I said, I am going to think about the undo command. > 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. Also something I will think about, but with no actual promise to implement it. Bye and thanks for your interest in enhancing apt-listbugs! -- 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
pgpgQA6oR9sge.pgp
Description: PGP signature
