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

Re: moving graphical installer to GTK 3



On Tue, May 18, 2021 at 01:27:56AM +0200, Cyril Brulebois wrote:
>Simon McVittie <smcv@debian.org> (2021-05-17):
>
>> I also think the beginning of Debian 12 would be a good time to
>> reconsider whether the graphical d-i mode is really the best way for
>> non-expert users to install Debian. The restricted capabilities of
>> udebs make d-i quite a "one hand tied behind your back" environment,
>> which was still a necessary evil a few years ago; but now that systems
>> with 512M RAM are literally given away with a magazine, perhaps that's
>> becoming less necessary than it once was?
>
>Maybe.
>
>Until now, I've been happy with maintaining (or at least trying to
>maintain) the status quo, which means an installer that works both in
>text and graphical modes, which can be preseed “as usual”, etc. It's
>definitely not getting many extra fancy features, but it seems to me
>it's been working rather reliably for a number of users, so…
>
>Of course it comes with a price regarding debuggability and you're
>unfortunately the one paying here, and I'm sorry for that.

So my own idea for how to proceed here is to make d-i a less
restricted environment. IMHO most of the core design of d-i is still
very gdoo, but it's a little too limited by its focus on small systems
(32MiB on the NSLU2, etc.) that are just not a target any more. We
could quite readily improve some of the more difficult areas of
today's d-i by adding support for (say) Python 3 instead of sticking
to the existing mix of mostly shell with C and perl bits.

Even if was decided to recommend that new users use live media for
installations, the flexibility of d-i is massively powerful, and we
shouldn't give up on it. The ability to support everything from a
serial terminal up to a graphical installer on the same media is
lovely.

But... I'd rather not start a discussion here about the future of d-i,
right at the end of a release cycle. Instead, I think we could do with
some focused face-to-face sessions at a debconf (or maybe a targeted
sprint) to work through the requirements and options properly.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
“Changing random stuff until your program works is bad coding
 practice, but if you do it fast enough it’s Machine Learning.”
   -- https://twitter.com/manisha72617183


Reply to: