Re: Proposed src/configure.c Patch
[ Sorry, resending, missed to actually Cc Colin! I don't currently have
my head where it should be. :/ ]
On Sun, 2022-04-10 at 10:52:56 +0200, Guillem Jover wrote:
> On Sun, 2022-04-03 at 22:29:42 -0400, Cameron Katri wrote:
> > I am helping write a GUI APT frontend and we wanted to add proper conffile
> > support, preferably be providing our own GUI alert with the possible
> > actions. I had realized that the best way to do that would be to add an
> > option to DPKG that allows a custom program to be specified to be used
> > instead of the default prompt when replacing conffiles. In src/configure.c,
> > the function deferred_configure_conffiles() calls promptconfaction().
> > promptconfaction() runs the function show_prompt() and parses the result. My
> > patch will modify promptconfaction() to execute an external program and
> > parse the result of that instead of the show_prompt() function. However
> > before I started writing anything I wanted to know if this is something that
> > could be upstreamed, and if you have any ways to improve this idea.
> The long-time plan has been to add debconf(7) support to dpkg. There's
> a very early draft (probably missing structure and much detail) at
> <https://wiki.debian.org/Teams/Dpkg/Spec/DebconfIntegration>, but
> AFAIR there are several things that would need changes first from the
> debconf side to be able to integrate this properly, which has seemed
> like a non-trivial endeavor. I think we have had some brief discussions
> about it in the past (might have been face to face) with Colin Watson
> (CCed, current maintainer) and Joey Hess (a previous maintainer), but
> I'm afraid we never got to do much with it, or write a concrete plan
> about it.
> There was a PoC by Sean Finney, adding debconf support long time ago,
> but that did not cover much of the above. This can be found at:
> I'm wondering though, whether you might be able to use dpkg's
> --status-fd (which can be specified multiple times, even if apt passes
> its own), where you'd get the prompt stuff via a structured output
> that you could parse instead? This would have the advantage of being
> readily usable right away.