On Thu, Nov 03, 2022 at 08:33:16AM +0100, Holger Wansing wrote: > Gioele Barabucci <gio...@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) [cjwat...@debian.org]
