Bug#628996: apt-listbugs: please use debconf
On Sun, 24 Mar 2013 01:09:43 +0100 Serafeim Zanikolas wrote: Hi guys, Hi Serafeim (and sorry for the very late follow-up), Attached a proof-of-concept for the advanced use case (in which the user actually wants to review which buggy packages to pin or upgrade). Consider this as a basis for further discussion, rather than something anywhere near a working patch. [...] I tested it by running it a few times. I understand that it's just a proof-of-concept script, but, well, it feels a little limited in its user interaction: I mean, can we present a multiple-action choice to the user (via debconf)? The current apt-listbugs text user interface displays the bugs that affect the installation/upgrade and then offers the user the following possible choices: * go on * go on and permanently mark the bugs as ignored * stop everything * display one bug log * pin some or all the packages * mark a bug as ignored * open a browser to display one bug log How can we do something similar via debconf without forcing the user to go through a tree of multiple successive screens (that would feel like a horrible call center menu system: dial 1 to learn about our fantastic promotional offers, dial 2 to receive commercial assistance, ...)? Going forward from here, one possibility would be for the apt-listbugs ruby script to invoke the debconf script (passing on the package/bug num/bug title info and getting back the user reply, via a tempfile or something along those lines). To be frank, I am not too enthusiastic about the idea to let a Ruby program invoke a POSIX shell script in order to get a user interface... If we have to implement a debconf interface for apt-listbugs, I would strongly prefer that it be done directly in Ruby. One issue with the debconf approach is that you can't fire up a browser to lookup a bug report before making the pin/upgrade decision (something that's possible with the current non-debconf based interaction). You also can't ^Z the debconf screen to do so manually. Any ideas about working around this? This looks like a severe limitation, if confirmed... Another issue that should be straightforward: use debconf in postinst to ask the user to choose between newbie and advance use (ie. whether one should go through the above dialog on every invocation, or let apt-listbugs upgrade only non-rc-buggy packages without asking) -- defaulting to newbie mode? This is much more similar to what is usually done with debconf, and should not be hard in itself, I think... What puzzles me is all the rest, as I explained above. Unfortunately I cannot dedicate time to the issue, for the time being. Maybe after the release of wheezy? Hopefully, not *too* long after? 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 pgpiJbyTnqMFI.pgp Description: PGP signature
Bug#628996: apt-listbugs: please use debconf
Hi Francesco, On Sun, Apr 07, 2013 at 07:22:27PM +0200, Francesco Poli wrote [edited]: On Sun, 24 Mar 2013 01:09:43 +0100 Serafeim Zanikolas wrote: The current apt-listbugs text user interface displays the bugs that affect the installation/upgrade and then offers the user the following possible choices: * go on * go on and permanently mark the bugs as ignored * stop everything * display one bug log * pin some or all the packages * mark a bug as ignored * open a browser to display one bug log How can we do something similar via debconf without forcing the user to go through a tree of multiple successive screens (that would feel like a horrible call center menu system: dial 1 to learn about our fantastic promotional offers, dial 2 to receive commercial assistance, ...)? I care about implementing the two basic use cases (newbie advanced) in the simplest possible interaction using debconf -- to ease integration with higher-level programs, so that Debian testing users (read: Desktop users that normally don't use a terminal) can benefit from latest updates while avoiding RC bugs. The rest of the choices are secondary for these two specific use cases. Newbies wouldn't even see the debconf screen and advanced users know how to lookup a bug report given its number. You've made it clear that you care about preserving all current choices. I don't agree, but I sense that a debate would be pointless, so that leaves us with one choice: default to the current (feature rich, terminal-based) interaction mode, and support the (simple scriptable) debconf one as an option eg. via an environment variable. Going forward from here, one possibility would be for the apt-listbugs ruby script to invoke the debconf script (passing on the package/bug num/bug title info and getting back the user reply, via a tempfile or something along those lines). To be frank, I am not too enthusiastic about the idea to let a Ruby program invoke a POSIX shell script in order to get a user interface... You get a bit more than a user interface: an implementation of the debconf protocol. If we have to implement a debconf interface for apt-listbugs, I would strongly prefer that it be done directly in Ruby. Sure, in a world of infinite available time we'd all prefer that. In reality, I'd go for the least amount of work which is a shell script, and I expect you to accept such a patch if it works as advertised. You are, of course, most welcome to put in the extra effort to implement a ruby debconf library. cheers, sez -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf
On Sun, 24 Mar 2013 01:09:43 +0100 Serafeim Zanikolas wrote: Hi guys, Attached a proof-of-concept [...] Hi Serafeim, I'll struggle to find a little bit of time soon to analyze what you sent. Sorry for not reacting quicker than that... :-( -- 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 pgpOQqfZIMj1S.pgp Description: PGP signature
Bug#628996: apt-listbugs: please use debconf
Hi guys,
Attached a proof-of-concept for the advanced use case (in which the user
actually wants to review which buggy packages to pin or upgrade). Consider
this as a basis for further discussion, rather than something anywhere near a
working patch.
To give it a try, save the attached files in the same directory (doesn't
matter where), make apt-listbugs executable and run it as root (debconf needs
to write /var/cache/debconf/{config,templates}.dat).
The template file declares the contents of the debconf screen, whereby the
multi-choice options are populated by the shell script via the $packages
variable.
The script overrides the seen debconf flag so that the question is asked
every single time (to override the default debconf behaviour; feels like a
hack).
Going forward from here, one possibility would be for the apt-listbugs ruby
script to invoke the debconf script (passing on the package/bug num/bug title
info and getting back the user reply, via a tempfile or something along those
lines).
One issue with the debconf approach is that you can't fire up a browser to
lookup a bug report before making the pin/upgrade decision (something that's
possible with the current non-debconf based interaction). You also can't ^Z
the debconf screen to do so manually. Any ideas about working around this?
Another issue that should be straightforward: use debconf in postinst to ask
the user to choose between newbie and advance use (ie. whether one should go
through the above dialog on every invocation, or let apt-listbugs upgrade only
non-rc-buggy packages without asking) -- defaulting to newbie mode?
cheers,
sez
--
Every great idea is worthless without someone to do the work. --Neil Williams
#!/bin/sh
set -e
export DEBCONF_DEBUG=developer
# debconf fails when DEBCONF_PACKAGE is set, but without it the
# template entry in /var/cache/dpkg/config.dat has an unkown Owner,
# which means that we can't remove it when apt-listbugs is purged.
#export DEBCONF_PACKAGE=apt-listbugs
# other values: text, dialog, kde, web (the two latter hang for me)
#export DEBIAN_FRONTEND=gnome
# source debconf libary.
. /usr/share/debconf/confmodule
# to be constructed on the fly, based on apt bts input
PACKAGES=package0 #abcdef (short description), package1 #abcdef (short
description)
# ask debconf to *always* show this question. without this, the
# question will be shown only the first time, even for different
# value sof $PACKAGES
db_fset apt-listbugs/select-packages seen false
# populate the template question with the list of RC-buggy packages
# and associated bug numbers
db_subst apt-listbugs/select-packages packages $PACKAGES
# priority has to be high-enough, otherwise priority overrides the seen:
false false
db_input critical apt-listbugs/select-packages || true
db_go || true
db_get apt-listbugs/select-packages || true
PACKAGES_TO_UPGRADE=$RET
# Close all fd's
db_stop
exit 0
Template: apt-listbugs/select-packages
Type: multiselect
Choices: ${packages}
Description: Select packages to upgrade, at your own risk:
The packages below will be pinned to the currently installed version, because
their latest version is known to have a serious bug.
.
If you know what you are doing, you can nevertheless upgrade certain packages
by selecting them in the list below.
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
On Tue, 19 Mar 2013 21:03:28 +0100 Serafeim Zanikolas wrote: [...] I think technical minded users would appreciate the same level of options currently provided by apt-get ran as root, ie. to be able to upgrade selected RC-buggy packages while pinning others. To me, it is of paramount importance to refrain from removing features or flexibility from apt-listbugs. In other words, I agree with you: let's not disappoint power users, in order to become friendlier to newbies! Less savvy users (eg. someone who can't tell the different between a DFSG-violation and system-wide breakage) would be served best by upgrading all upgrade-able packages except for those that are RC-buggy. In practise, this means pinning any RC-buggy packages (what the patch for #441689 does) and proceeding with the upgrade (after an apt-get re-invocation, or whatever action is required for the pinning to become effective). Yes, this looks like a possible use case. Do you agree about these use cases or do you have others to suggest as more important? Nothing else comes to my mind for the time being. Anyway, if we manage to add features, without removing previously implemented ones, we should automatically preserve existing use cases (even those we are not aware of!). Back to mechanics: The current non-interactive default (with --force-no) of aborting the whole upgrade in the face of any RC bug means that users are denied of (potentially security-critical) updates to packages that are safely upgrade-able. I consider this unacceptable if we're serious about supporting Debian testing. It's definitely sub-optimal: personally, I would not use apt-listbugs that way, but, after all, I don't consider myself to be a total newbie... This brings us back to the above distinction between more and less sophisticated use cases. Severity based filtering (-s) seems meaningless to me. I'd never do blind upgrades based on a ignore bugs up to X severity policy, because that doesn't say anything about the packages and package features that I rely on as a user. Please note that the current apt-listbugs default behavior is to ignore any non-RC bug. I consider this to be a reasonable default, especially taking into account that the behavior may be configured differently by the user. -- 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 pgp2tBmxK7DwS.pgp Description: PGP signature
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
On 19 March 2013 07:07, Francesco Poli invernom...@paranoici.org wrote: On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: 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? No, I meant only to exclude the other bug report which is now quite unrelated to this topic. :-) 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. I see. So, except for the previous hanging issue with packagekit, apt-listbugs is more-or-less compliant in its operation and, as per your later comments, its fallback behaviour is somewhat configurable. - abort always when RC bugs. The second is, IMO, the more reasonable default. I believe it's the currently implemented default. Yes. (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. Packagekit-backend-aptcc uses libapt-pkg4.12, which certainly does send the hook information. The reason for the apt-listbugs hanging must lie in some other aspect of the running environment. [...] 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... Yes, my mistake. Anyway, I think we all like to at least test a debconf interface and get some interaction in situations without /dev/tty. So some project for the near future. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
Hi guys, On Tue, Mar 19, 2013 at 12:07:20AM +0100, Francesco Poli wrote: On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: [...] On 17 March 2013 16:17, Francesco Poli invernom...@paranoici.org wrote: [..] · -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. [..] - 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. It might be useful to forget about mechanics for a moment and think about the use cases that we'd like to support for Debian testing users of high level package managers (packagekit and the like). I think technical minded users would appreciate the same level of options currently provided by apt-get ran as root, ie. to be able to upgrade selected RC-buggy packages while pinning others. Less savvy users (eg. someone who can't tell the different between a DFSG-violation and system-wide breakage) would be served best by upgrading all upgrade-able packages except for those that are RC-buggy. In practise, this means pinning any RC-buggy packages (what the patch for #441689 does) and proceeding with the upgrade (after an apt-get re-invocation, or whatever action is required for the pinning to become effective). Do you agree about these use cases or do you have others to suggest as more important? Back to mechanics: The current non-interactive default (with --force-no) of aborting the whole upgrade in the face of any RC bug means that users are denied of (potentially security-critical) updates to packages that are safely upgrade-able. I consider this unacceptable if we're serious about supporting Debian testing. Severity based filtering (-s) seems meaningless to me. I'd never do blind upgrades based on a ignore bugs up to X severity policy, because that doesn't say anything about the packages and package features that I rely on as a user. -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf
On Mon, Mar 18, 2013 at 08:00:51PM +0800, Daniel Hartwig wrote: On 18 March 2013 18:56, Serafeim Zanikolas s...@debian.org wrote: [..] If I understand correctly, debconf can only be used with predefined templates, thus predefined generic policy questions (as opposed to questions that can be different on every invocation). Yes, the templates are predefined, but the questions are not. A question is a template with potentially some substitutions made. The substitutions can be arbitrary, including multi-line strings, and there should be little if any flexability lost. Effectively it is no different to printf type string templates, coupled with pre-determined responses (such as, what action to take for pkg X with bugs Y). Daniel, thanks for taking the time to clarify. It makes sense now. Francesco, implementation details aside, are you OK with the direction? -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]
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
Bug#628996: apt-listbugs: please use debconf
On Mon, 18 Mar 2013 14:33:11 +0100 Serafeim Zanikolas wrote: [...] Francesco, implementation details aside, are you OK with the direction? More or less, but I believe that implementing a debconf frontend for apt-listbugs is not a small change: hence, I think it should be seen as a mid-term/long-term goal. 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 pgpHJyUSYhiHx.pgp Description: PGP signature
