On Thu, Nov 03, 2022 at 08:33:16AM +0100, Holger Wansing wrote:
Gioele Barabucci <gioele@svario.it> wrote (Sun, 28 Aug 2022 09:19:53 +0200):
you probably have seen the bugs reports [1] and the MRs [2,3] that I recently opened related to the creation and the use of `debconf-common`.
With these changes [4,5,6] applied (and a few unrelated changes) I have been able to mmdebootstrap a number of VMs in which classic debconf is
not used at all, neither at installation time nor afterward.
I'm confident that a debconf-free unstable for base systems could be achieved before the freeze with little effort.
[1] https://bugs.debian.org/1018261
[2] https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/11
[3] https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/17 [4] https://salsa.debian.org/gioele/debconf/-/commits/debconf-common-pkg [5] https://salsa.debian.org/gioele/cdebconf/-/commits/depend-debconf-common
[6] https://salsa.debian.org/gioele/cdebconf/-/commits/independence
Any objections against this approach?
I commented on
https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/11. While
I don't have a fundamental objection to it (and indeed have made some
attempts towards the same goal in the distant past), and while I
definitely applaud attempts to make progress here, I don't think we
should try to do it to a deadline.
The confmodule-level issues I raised can probably be dealt with
relatively easily (though given that they weren't spotted beforehand, I
suspect there is a bit of a QA gap here). However, if we're looking at
getting cdebconf going fully in installed systems, then somebody really
needs to be committing to figuring out full cdebconf compatibility for
all the various random features that aren't needed in d-i but that at
least some people will be relying on in the installed system - the full
range of frontends, databases, protocol details, and so on. We don't
even have things like frontend name compatibility where cdebconf has
"close enough" frontends to debconf's at the moment; in my mind that
would be part of (almost certainly not all of) a bare minimum of
compatibility here.
I understand that a prototype implementation doesn't strictly need all
this stuff for minimal functionality, especially if there isn't much
user interaction involved, and so it looks like having cdebconf-only
installed systems is just a few patches away. However, as soon as it
starts to be possible to install cdebconf-only systems, people will
start trying to do so and expect us to support the results, and are
likely to complain about the gaps. So I don't think this can be done
before the freeze (and honestly I think there's enough to do that me
replying more promptly wouldn't have made a significant difference to
that), but there's definitely stuff for people to get their teeth into
if they want to make progress on this goal that's been open since at
least 2003.
--
Colin Watson (he/him) [
cjwatson@debian.org]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)