# d-i (Sledge, kibi) ## Catching up, 2022-05-22 ### Do we want to keep maintaining d-i? Hell, yes! - Still convinced of the pertinence of d-i as it is, even if we understand it can be a pain for some maintainers to carry udebs forever. We're happy to provide any help they might require (we usually do provide patches when unsuspecting package maintainers upload things that stop working). ~20years old, largly works, known bugs but still relavent today suggestions to replace it have so far gone nowhere udebs - perhaps not so much needed today, then it was needed for size todays minimum system probably has 0.5GB RAM (not MB!) Thinking of re-implementation in Python for example (help wanted) ### What's the most crucial part d-i is missing right now? - Enough with shell and C: we'd like to inject something that would be easier to work with; we're thinking about the Python interpreter, even if that means pulling C++ runtime (which we avoided until now). It might be feasible to just pull a few .deb packages and copy what we need, instead of adding then maintaining .udeb packages. - With a Python interpreter pulled during the build, existing d-i packages could be migrated one by one, replacing shell pipeline mazes with Python modules, functions, etc. - On the downside: space and memory requirements will take a bump, but 32M SLUGs are long gone, so it's probably acceptable if it makes everyone's life easier. This includes being able to test things with the usual Python tooling. - Speaking of Python… mmdebstrap needs it and Perl. Maybe it could replace good old debootstrap at some point? Regardless of possible performance boost, it seems to be getting “upstream care” (not sure we can say debootstrap does). We might want to talk with josch at some point. Of course, if we were to go that route, we would need some kind of commitment to keeping it d-i friendly. ### Required work before Debian 12 - Resuming (at leat semi) regular d-i releases. openQA will help with this - yes! I currently have a MR pending for testing live images (which I ought to be grabbing today) my branch2repo gitlab-CI widget is pretty-much ready for wider use, and allows one to test changes done to d-i rather well, so that combined with openQA ought to make development a bit easier for people. Along with that, turning on CI on salsa for more d-i components, and trying to keep things green would help people develop confidence in contributing. Regarding mention of hardware farms & testing -- people have managed to setup openQA to test real laptops, with servos to press the power buttons, etc. /me has slightly more spoons than in previous years, and should spend time looking at this. - Porting cdebconf-gtk to GTK+ 3 or 4. We dodged a bullet for Bullseye thanks to Simon McVittie, but we shouldn't push our luck. - this is the #1 issue - Redesigning is not a small project. - But it can yield some bonuses, maybe support for HiDPI displays. - We should be able to get rid of unmaintained VTE, which should make the release team happy (unactionable RC bugs because the package is in the d-i set). - Drop win32-loader? ### What could really be better - Partitioning: nick black came up with a growlight alternative to partman. We haven't heard back for a while, Sledge pinged. - Partitioning: even without replacing partman (or offering an alternative), it should be possible to have more “guided” recipes ways to describe common setups, so that some steps could be automated; possibly accepting parameters. Example: RAID1 on two disks requires familiarity with (1) booting constraints – BIOS or EFI — (2) bootloader knowledge — BIOS Boot partitions, etc. (3) tricky tricks knowledge — RAID metadata for ESP, no-nvram, etc. - Speaking of installing on two disks, that's not supported by grub-installer at the moment (without patching). ### Extra - Backports! But of course regular d-i releases should take priority. The patchset was rather small, and even without checking, it should be feasible to refresh it. - Ideally though, we would be moving the kernel install from early in the install process to after apt-setup, so that the backports service has been configured, avoiding the need to install the stable kernel, before (later) installing the backported kernel in addition. (Even if having both shouldn't be a huge issue.) - Firmware - adding better support for the non-free-firmware stuff - Busybox - any stuff to do? Images ------- CD media is no just too small - dropped NetInst is always the prfered option - it is a small image and pulls back packages fron the net on demand Larger images available, compleate set available across DVD / BD large image just works on a "USB stick" (iso-hybrid just dd the image directly to usb stick) if you need the whole archive offline - run your own mirror in windows use Rufus in place of dd Bookworm ======== o Drop i386 images (keep archive, but nobody can buy this hardware today) Beware of the multi-arch detection mechanism, and dual-architecture images ? o include Thomas' script to merge multiple iso images - it works o Live images - reduce number? - just for default desktop? - only ship live from a desktop team activly working on live? Live images: rclobus speaking here... I'm currently bottlenecked, but I definitely want to (re)activate them. A Calamares test for the live images is one of the next steps I'm planning o RPI images now available (gunnar) o WSL iamages - not yet official o Blends - edu is really the only active we see - thanks debian-edu team Open Questions o Download Site - What images should we provide / promote? o Automatically detect local mirrors Question: automatically detecting local mirrors, do you also mean proxies? No (at least I beleive not) - Di gives the option to point at a mirror (either on the inet or a local address, containing an archive) one option might be to assume that if there's some well-known hostname in the local DNS, one tries to grab a preseed file from it, which would allow people to preseed their local mirror etc. (e.g. look for http://_DEBIAN_PRESEED_HOST.$localdomain/d-i/$release/preseed.cfg or some such) the name "mirror" currently does not work dor Di for a local mirror - you need to add the local domain name (once installed apt copes) o Front option - Just give me a debian install and make all the decisions for me o RPi we need to build in debian official infrastructure o Can we have Di on RPi? - these are normally a 'live' / pre-build image - contain firmware (needed for RPi) so not (yet) official o OEM images - a bit like gnomes 'first-boot' tool - use a similar tool to enable / configure user setup on 1st boot, alows OEMs to clone many new machines