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

Re: rfc: growlight as d-i partman replacement



[debian-derivatives dropped from cc]
[93sam, pabs added to cc] [0]

nick black left as an exercise for the reader:
> Christian PERRIER left as an exercise for the reader:
> > Quoting nick black (nick.black@sprezzatech.com):
> > > As said, you can find a growlight udeb in the SprezzOS repositories, where it
> > > is actively used in our d-i-derived installer:
> > It's quite likely that the first step is then to have growlight in
> > main Debian, isn't it?
> 
> Indeed. I will file an ITP.

sorry to revive an eight-year-old thread, but there has recently
been news on this front =]. you might find a web archive useful
for context [1].

growlight (as a deb, not an installer component) was admitted
into the archive last year, and shipped today as part of
bullsye: https://packages.debian.org/testing/source/growlight.
i have been actively maintaining and extending it for the past
decade, thought the SprezzOS derivative from which it originated
is long defunct.

debconf21 allocated twenty minutes to discussing this idea [2],
and i thought i'd bring it up here so as not to surprise anyone.

my main arguments for why it might be worth looking at include:

* features and new technologies are added to growlight as they
  emerge as a natural part of its post-install development [3],
  whereas partman presumably requires fresh dev effort for any
  feature desired in the installer.

  as an example, creating btrfs aggregates requires some
  conceptual work, some minimal ui work, and some minimal
  integration, independent of system installation. growlight
  would gain this functionality as due course, as disk
  management is its raison d'être, much more so than it is d-i's.

* can present dynamic information about multiple devices
  simultaneously, and perform most actions in parallel. running
  e.g. concurrent mkfs operations can be displayed and managed.

* partman AFAIK only gets run during installation, not in the
  course of system administration. it is thus possible that
  growlight would get more and/or more varied testing.

* it's already been built as a udeb and used as a partman
  component, and proven out in the d-i context (see video proof
  at [4], admittedly from 2013). so we could just start messing
  around with it pretty much tomorrow.

of course, there are plenty of reasons why a change might be
undesirable, and i hope to address many of them in my talk. most
concerning to me is preseeding, which i would be very hesitant
to either (a) invalidate or (b) recreate.

so i hope you all watch the talk! hopefully it won't be a grand
waste of everyone's time.

--nick

[0] sam because he's the current QA contact for partman, paul
    because he was so active on the derivatives list.
[1] https://lists.debian.org/debian-boot/2013/02/msg00122.html
[2] https://debconf21.debconf.org/talks/3-proposing-a-new-d-i-disk-preparation-tool-growlight/
[3] https://nick-black.com/dankwiki/index.php/Growlight#Some_capabilities
[4] https://nick-black.com/tabpower/growlight-return-of.mp4

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

Attachment: signature.asc
Description: PGP signature


Reply to: