Source: cdebconf
Version: 0.265
Severity: critical
cdebconf 0.265 dropped the "debconf" dependency, that Joey Hess
"temporarily" added in 2007 with cdebconf 0.123[1]. This was added to
"avoid anyone breaking their systems by removing debconf, which
dependencies now allow".
Unfortunately, that removal was premature, and indeed, it is now
possible for someone to install cdebconf 0.265, remove debconf from
their system (which apt will happily do), and for hundreds of unrelated
random packages to break, in the same way that was reported back then
with #443627.
Example steps to reproduce:
# on a clean chroot or container, e.g. podman run -it --rm debian:sid
apt install -y cdebconf
apt purge -y debconf # this was not previously possible, but now is
# pick a random package that uses debconf, in this case tzdata
apt purge -y tzdata # in case this was already installed
apt install tzdata # kaboom
I believe the reporter of #1006492 misunderstood the original change and
therefore that bug is invalid. Additionally, I believe the resolution of
#328498 to be premature, given that cdebconf is clearly not the default :)
The underlying cause is that cdebconf Provides: debconf-2.0, to indicate
that it provides the debconf 2.0 protocol, because that was its original
intention. However, it does not do so; it only did transitively, because
of the debconf dependency. Packages in the archive depend on some
variation of "debconf | debconf-2.0" expecting certain facilities
(binaries, shell libraries, etc.). However, cdebconf does NOT currently
provide any of these.
At least these differences exist:
* cdebconf provides its binaries under /usr/lib/cdebconf, not /usr/bin
(presumably to avoid a Conflict with debconf), and thus standard
binaries that maintainer scripts (and administrators) expect, cannot
be found.
For example, /usr/bin/debconf-set-selections,
/usr/sbin/dpkg-preconfigure or /usr/sbin/dpkg-reconfigure.
* cdebconf does not ship /usr/share/debconf/confmodule. Many
maintainer scripts expect this. tzdata, mentioned above, is one of
them.
* cdebconf does not ship the Perl implementation of
Debconf::Client::ConfModule, but the debconf package does. There are
packages that expect that a "debconf-2.0" dependency will make this
available to them. For example /usr/sbin/pam-auth-update from the
libpam-runtime package uses it, but the package depends "just" on
"debconf (>= 0.5) | debconf-2.0, debconf (>= 1.5.19) | cdebconf".
* Finally, cdebconf does not include a debconf-apt-progress
implementation. See #537523 for an old bug describing this, as well
as a request for the passthrough frontend.
Going forward there are a few options:
* Revert the change and depend on debconf again. This is the safest
option, as this has been the status quo since 2007.
* Remove the debconf-2.0 Provides from cdebconf. This is, arguably,
the option that would maximize correctness, given cdebconf is not
really providing the facilities expected by debconf-2.0. It's
unclear to me what this could break, though.
* Longer-term... actually create feature parity between cdebconf and
debconf, potentially even switching to cdebconf by default, as Joey
originally intended. This will likely include _at least_ the
following:
- Resolving the items in #537523 (debconf-apt-progress).
- Splitting Debconf::Client::ConfModule from debconf to a
libdebconf-client-confmodule-perl package, and either have
cdebconf depend on it, or perform an MBF to ask downstream users
to add this dependency explicitly. (Which of the two depends on
whether one considers this Perl API part of the "debconf-2.0"
protocol or not.)
- Shipping /usr/share/debconf/confmodule by cdebconf, moving
cdebconf's binaries to /usr/bin and /usr/sbin, adding a Conflict
again, and deprecating DEBCONF_USE_CDEBCONF.
Regards,
Faidon
1:
https://salsa.debian.org/installer-team/cdebconf/-/commit/b4dfa070d676917f12f58cc52fe46fe2f4094fc3
