Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe
Control: reopen 628996
Control: retitle 628996 apt-listbugs: please use debconf
#Control: tags 628996 - moreinfo
On 17 March 2013 16:17, Francesco Poli <invernomuto@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.
Reply to: