Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade
On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote:
> On 2021-09-10 16:51, Colin Watson wrote:
> > The only way to fix what libc.preinst is currently trying to do would
> > be:
> >
> > * Fetch the current debconf frontend *without* first sourcing the
> > confmodule, e.g. using something like "echo GET debconf/frontend |
> > debconf-communicate" which I *think* is safe as long as you haven't
> > sourced the confmodule yet;
> >
> > * Decide whether to use debconf based on this and other information;
> >
> > * Only source the confmodule if you've positively decided to use it.
>
> debconf-communicate might be safe, but its manpage explicitly says it
> should not be used in maintainer scripts.
Strictly, it says "a maintainer script of a package that uses debconf".
I think what that really means is that it shouldn't be used after
sourcing the debconf confmodule (which is normally the same as using
debconf since nearly everything sources it right at the top - but this
is a weird edge case). The point is to avoid having multiple processes
with the debconf database open at the same time.
Put another way, for this purpose, libc6.preinst isn't really a
maintainer script that uses debconf until it sources the confmodule.
> I gave a try with debconf-show instead. I have attached a totally
> untested patch to check that we agree on the way to do it.
I think you forgot to attach the patch?
I wouldn't completely veto using debconf-show in this very specialized
situation, as long as it came with a substantial comment explaining
what's going on so that nobody else is tempted to copy it. However, the
output format of debconf-show isn't guaranteed, so I'm not very happy
about it being used mechanically like this. I'd prefer
debconf-communicate if we can ensure that it works in this context,
notwithstanding its documentation.
> > But a simpler approach might be to update debconf in buster with the
> > change from 1.5.76 to check whether whiptail/dialog is usable before
> > trying to use it, and then remove at least some of this fragile and
> > broken code from libc.preinst. At the very least, USE_DEBCONF=1 must
> > always be set if (and only if) the debconf confmodule has been sourced.
>
> While it is probably a good idea to backport that change in buster to
> limit to reduce the risk, we don't require people to upgrade to the
> latest buster release before starting an upgrade.
>
> On the other hand, given that bullseye has a fixed debconf, I fully
> agree that we should drop that fragile code for bookworm.
We probably agree on both points here.
> > I'm currently seeing if I can construct a reduced reproduction recipe
> > based on Neil's logs, since it evidently depends on exactly which order
> > apt chooses to unpack things early on, and it would be very helpful to
> > be able to test fixes properly.
>
> Thanks, tell me if you need help on that.
I managed to reproduce the reported bug by taking Neil's full package
list, mangling it to roughly make sense on buster, installing all of
that, and then doing "apt upgrade && apt full-upgrade" (my own habit is
just to do "apt full-upgrade", but in this case the initial "apt
upgrade" is crucial). I'm now trying to more or less bisect the package
list to find something rather more minimal; this is a slow process, but
no roadblocks so far, and I'll let you know when I have something.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: