Hi nick, [ cc += debian-boot@ ]
nick black <dankamong...@gmail.com> (2021-09-27): > Marc Haber left as an exercise for the reader: > > But maybe an alternative? I find the partitioning step one of the > > most error-prone and hard-to-use parts of non-trivial Debian > > installations. > > so overall, i've got to say the feedback i heard here was a lot more > positive than i was expecting, though there was a bit less than i had > hoped for. but perhaps something that can be touched would see more > interest? FWIW I've followed the answers to your mail over the last few days, but I haven't had a chance to look at either the video or the slides (only 4 days before your initial mail and the one I'm replying to…). At first glance, it seems fine to be experimenting with a different partitioner; of course all people are somewhere on the love/hate spectrum regarding partman and the zillions of partman-* packages, but it's indeed a shell maze and it *probably* could use some heavy lifting. I keep hoping that simple use cases are made simple(r)… maybe growlight could help there (e.g. “I'd like soft RAID1 with encrypted LVM, all that with a UEFI boot — therefore ESP —, without being a storage wizard”). I suppose some step (once you've experimented on a growlight-only d-i) would be to have both partman and growlight, and let people choose (maybe with a flag at boot time, or by entering expert mode or whatever), until we have a better idea what works, what doesn't, what can be fixed, what cannot, and until a decision is made for the next Debian stable release. Leaving the technical integration aside for a moment, one question that comes to mind is whether this would be a one-shot contribution or some kind of longer commitment to maintain that different partitioner. I seem to remember earlier attempts at revamping the partitioning step, which stalled eventually. (Your recent mail to debian-newmaint@ is a hint; your apparent steadiness of those packages maintenance-wise is another; and your apparent interest in adding support to possibly missing features yet another.) Of course, one might object that the question is moot as there isn't much active development on partman components (even if some patches have been submitted over the last few days), but at least that's a known (imperfect, but…) beast. > given that no one seemed to reject the idea out of hand, i'm going to > go ahead and rebase my work from 2012 (or more likely look at it once > and redo it) in a Salsa fork of d-i, and make some installation media > available. forgive me for likely only having x86 available at first. > i'll try to have this done within a week or so, and put it up on my > server. people can then give it a whirl. Feel free to touch base with debian-boot@ and/or debian-cd@ once you have a working proof of concept that some people have toyed with; we can discuss how the “alternative” part could be implemented (different images, or both partitioners ship together, with some option/selection — people might remember GRUB vs. LILO). I cannot guarantee a timely answer (life tends to keep me busy), but you shouldn't see a lack of answer after just a few days as if people were not interested. > note that there would still be some questions where i'd need input > from Project members (as noted in my Debconf [0] presentation), > particularly regarding translation (even if i can lift significant > portions from partman, i'd need it looked over) and facilitating > accessibility technology. I won't delve into specifics (I did mention I didn't do any research, right?) but as long as your application can be controlled via debconf, it should fit right in within all our installation images (text based installer, graphical installer, network-controller installer, etc.), and things like localization and accessibility support should be automatic (of course you'd still need to get the translation process bootstrapped for your own strings at some point, but the inner workings should all be there already). Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
