On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: [...] > On 17 March 2013 16:17, Francesco Poli <invernom...@paranoici.org> wrote: > > On Sun, 17 Mar 2013 10:41:52 +0800 Daniel Hartwig wrote: > > > > [...] > >> Debconf may provide a suitable interface there > > > > Please see the bug log of #628996 for more details about a possible > > Debconf frontend and the related difficulties... > > Thanks. I reopen that bug
I knew that mentioning that old bug report would cause it to be revamped... :-/ Do you think you should set yourself as submitter of the bug report? > as the current workaround (i.e. making > apt-listbugs a no-op) is not adequate. I agree that disabling apt-listbugs for packagekit users is sub-optimal, as I myself commented a while ago on this very bug log. > What follows is a somewhat > verbose justification and answer to some of your previous questions. > Responses should go to #628996 only, please. Excluding your address and also Serafeim's one? > > Apt-listbugs is run in a similar context as package maintainer > scripts. Debian policy #6.3 applies: > > Maintainer scripts are no longer guaranteed to run with a > controlling terminal and must be able to fall back to > noninteractive behavior (debconf handles this). Maintainer > scripts may abort if there is no controlling terminal and no > reasonable default for a high-priority question, but should avoid > this if possible. This is already complied with, even though in a somewhat brutal way. Quoting apt-listbugs(1) man page: · -n, --force-no Assumes that you select no for all questions. This option is assumed if stdout is not a terminal or if /dev/tty cannot be opened. Hence, I would say that, when there is no controlling terminal, apt-listbugs falls back to a non-interactive behavior (assuming a negative answer for each question that would otherwise be asked to the user). This implies that, if the upgrade or installation risks introducing RC bugs into the system, then the (non-interactive) apt session is forced to stop. Otherwise, everything goes on, as if apt-listbugs were never invoked. > > Debconf is the standard way to handle this type of user interaction > during Apt activity, I agree that using debconf would improve the flexibility of user interaction. As I have previously said in this very bug log, I had difficulties in figuring out how a program written in Ruby can interact with the user through debconf. > and provides more control to the user (i.e. using > DEBIAN_FRONTEND and preconfiguring). At the moment, current > non-interactive behaviour is one of: > - avoid running apt-listbugs, due to work-around for #662983; Wait, the workaround for bug #662983 was implemented exactly to switch to non-interactive behavior in the absence of a controlling terminal... > - abort always when RC bugs. > > The second is, IMO, the more reasonable default. I believe it's the currently implemented default. > Ideally, the minimum > severity of bugs to cause abort should be configurable but that is yet > another wishlist :-) Assuming I am not misinterpreting what you wrote, this is already possible: by modifying /etc/apt/apt.conf.d/10apt-listbugs the user may add options to the apt-listbugs invocation, among which the -s option may be used to define which bug severities he/she is interested in. [...] > Francesco, you previously asked two questions: > > Open questions: > > > > (A) how can a program written in Ruby use debconf to interact with the > > user? > > Any program can directly use the debconf protocol as documented in > debconf-devel(7). No library is required, though some minor changes > to initiate debconf interaction will be. If I recall correctly, I tried to understand how to do this, but failed miserably... :-( > > There is a sh library, and probably perl and python also. These may > or may not be useful. > > > (B) will a DebconfFrontend be (necessary and) enough to make > > apt-listbugs work well with packagekit? > > It depends what you mean by ‘work well’. I mean that, during this bug log, I began suspecting that packagekit did not send the hook info to hook scripts. If this is the case, then using debconf would not be enough to let apt-listbugs work with packagekit. This was never clarified. [...] > Though packagekit by design does not allow interaction with the user, Wait, what do you mean? I was under the impression that user interaction through debconf was allowed... > other Apt frontends have trouble with apt-listbugs (e.g. aptitude) Wait, let's not dramatize. I use aptitude with apt-listbugs everyday. The only "trouble" is that users should become root with "su -" before invoking aptitude, rather than starting it from their regular account and relying on the internal gain-root-privileges mechanism. [...] > I am not a user of apt-listbugs, I would like to encourage you to give it a try and familiarize with it, so that you may find out more about its strengths and weaknesses. > though I do value its place in the > Apt world and do not wish it to become a second class citizen rought > with work-arounds and pitfalls. I will contribute some effort to the > development of a debconf interface after the Wheezy release. Thanks for your offer. I hope I'll find the time to implement it, with your help. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpq4e2Dm96Yq.pgp
Description: PGP signature
