Control: reopen 628996 Control: retitle 628996 apt-listbugs: please use debconf #Control: tags 628996 - moreinfo
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 as the current workaround (i.e. making apt-listbugs a no-op) is not adequate. What follows is a somewhat verbose justification and answer to some of your previous questions. Responses should go to #628996 only, please. 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. Debconf is the standard way to handle this type of user interaction during Apt activity, 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; - abort always when RC bugs. The second is, IMO, the more reasonable default. Ideally, the minimum severity of bugs to cause abort should be configurable but that is yet another wishlist :-) Using debconf in combination with updates to the APT hook protocol (#671726) will restore functionality, avoid the current /dev/tty hacks, work with the maximum number of Apt frontends (packagekit, aptitude, apt-get, wajig, etc.) and provide more flexability. In particular, interaction with the user is possibly available with any debconf frontend, even in the absense of a controlling terminal. Apt-listbugs provides a safe guard against introducing known RC bugs to a system. I believe we all agree that it should not be disabled simply due to lack of /dev/tty access, and that it should also take the maximum opportunity to interact with the user. 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. 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’. ‘Work well’ can not require the presence of an interactive terminal, as given debian policy #6.3 quoted above [1]. It will be enough to at least have a sensible and configurable non-interactive default, and provide greater opportunity to interact with the user through non-terminal debconf frontends. Though packagekit by design does not allow interaction with the user, other Apt frontends have trouble with apt-listbugs (e.g. aptitude) and using debconf will certainly facilitate more interaction here. I am not a user of apt-listbugs, 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. Regards [1] If you disagree with this, then apt-listbugs is not suitable for hooking in to Apt's Pre-Install-Pkgs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org