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

Re: Screen support (was: Next d-i alpha release: late June)

Dear KiBi,

Sorry for not being able to reply earlier.
You feedback keeps me thinking a fix.

On Tue, Jul 5, 2016 at 7:35 AM, Cyril Brulebois <kibi@debian.org> wrote:
> I still disagree with the UI changes it imposes on everyone, for the
> reasons I've already given.

During RFC stage of adding screen-udeb, firstly I though it's not
necessary for normal PC, which is not exact the same with "everyone"
you mentioned but should be close to, however a few feedbacks
convinced me that normal PC still need screen-udeb [0][1][2].

[0] https://lists.debian.org/debian-boot/2016/04/msg00369.html
[1] https://lists.debian.org/debian-boot/2016/04/msg00377.html
[2] https://lists.debian.org/debian-boot/2016/05/msg00004.html

I think the solution below is a middle ground, which I guess it can be
accepted by everyone.
- Keep screen-udeb in "common" for everyone, but don't start it
automatically on i386/amd64.
- Create a new "MEDIUM_SUPPORTED" or new folder under build/pkg-lists/
for i386/amd64, which start screen by default when it's not in gtk
mode (detecting in runtime)

In this way, for normal image, the screen wouldn't start by default,
and headless PC owner can choose the later/new image, or choose the
normal image and start screen manually (specifying

> I'm not OK with installing something everywhere except where it breaks
> stuff. Instead, it should be specifically installed where it's needed.
> (That remains to be determined.)

I guess you mean gtk installer will never use screen, so screen-udeb
should not be placed in gtk image.
What I thought was that it should be convenient to have one CD/DVD to
fix different task as much as possible, which shares the same idea as
multi-arch image, so it'd be nice to have screen-udeb in gtk
installer, which can start by specifying DEBIAN_FRONTEND=newt when we
install on headless PC.

My proposal above already takes this into account, so should be no problem.

I didn't implement the proposal yet, just hope we can make a consensus first.

Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Reply to: