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

Re: Request for English debconf template review



[We seem to be getting into technical details of the service detection,
rather than of the translation; perhaps debian-devel is the better list for
this?]

On Mon, Sep 03, 2007 at 01:49:52PM +0100, Justin B Rye wrote:
> Steve Langasek wrote:
> > But your other message made me think a bit more about this, and I realize
> > that the size can easily be brought down by splitting the display manager
> > paragraph into a separate debconf note:

> > - if $DISPLAY is not set in the environment, automatically include
> >   xdm/kdm/wdm in the service list without warning
> > - if $DISPLAY is set in the environment, automatically exclude these
> >   services from the list, but show a second debconf question informing the
> >   user that they need to be restarted.

> > Does this sound reasonable?

> As it happens, at this very moment I have two logins:
> * an aptitude session running on a VT (with no $DISPLAY), and
> * an X session with unsaved work.
> How about checking "pidof X"?

This doesn't tell you if X was started from kdm, wdm, or xdm, which is
what matters.  Users shouldn't wind up with this error message if they've
started X from gdm or using startx.

I didn't realize that pidof was part of the essential system, though.  That
does require an additional assumption on the part of the maintainer scripts
(process name == init script name == package name rather than just init
script name == package name), but it seems acceptable in this case given
that there are only three packages at issue.

The tradeoff here is that it will work better than $DISPLAY detection for
users who have an active X session but are upgrading from an unrelated
terminal, and it will work worse for users who have a display manager
running but aren't logged in.  For my part, I find it preferable to err on
the side of restarting too much rather than too little, given that the admin
has the opportunity to correct the list of services to restart at the time
of the upgrade, but non-admin users have no opportunity to fix the login
screen if their admin upgrades the system without paying attention to this
issue.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: