[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: partman, growlight, discoverable partitions, and fun

Hi nick,

[ cc += debian-boot@ ]

nick black <dankamongmen@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

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).

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: