[Pkg-gpm-devel] Bug#289165: gpm: Unnecessary question about X

Helge Kreutzmann Helge Kreutzmann <kreutzm@itp.uni-hannover.de>, 289165@bugs.debian.org
Sat, 8 Jan 2005 11:31:05 +0100


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Peter,
On Fri, Jan 07, 2005 at 11:20:06AM -0600, Peter Samuelson wrote:
> [Helge Kreutzmann]
> > I was updating, and I was asked:
> > Usually, GPM should be started or restarted when it is installed or
> > upgraded.  But when X is running and trying to use the same mouse
> [...]
> > But there is *no* X running on this machine currently! (I do not
> > start X every time, just when I need it). Also I always run apt-get
> > on the console anyways.
>=20
> It's difficult to reliably detect the case where X is running when gpm
> is being upgraded.  The package used to attempt this, but the check was
> error-prone, so we chose to remove it and display the warning
> unconditionally.

I do see the point. But I sincerly hope that the check will be
re-introduced in the future (in an improved version). I strongly
prefer to be asked only relevant questions.

> As it happens, if gpm and X are correctly configured, the restart is
> quite safe.  However, forcing incorrect but working configurations to
> break arbitrarily is not a good thing.  Especially since, historically,
> a lot of bad advice about configuring gpm and X has floated around.

Then I hope you work together with the X maintainers to eliminate
those broken installs that this issue becomes moot in the future.

> > Would this be possible to turn this into a note in NEWS? (i.e., is it
> > sufficient if restarting while in X fails, that the user jumps to a
> > terminal and restarts again?).
>=20
> Nobody reads NEWS.  Nobody reads FAQs.  Nobody reads changelogs.  For
> something which will potentially freeze the user's mouse cursor (and
> this will happen during a potentially long 'apt-get upgrade' process,
> so the user may not even have the terminal window *visible* to
> determine what happened), I think I'd just as soon force the user to
> see the warning.

Well, then *I* am nobody. And apt-listchanges obviously was programmed
for nobody. And the NEWS feature of apt-listchanges was only added
because the maintainer of apt-listchanges had to much time. And the
documentation packages are only existing because Debian wants to waste
bandwidth. Not to mention the Linux Documentation projects and so on...

Sorry, this is completely invalid. I adminster several machines (more
below) and of course I read changelogs, and NEWS. Thats what they
exist for. I *strongly* dislike being prompted unnecessary things. I
know what a logfile is for. IMHO if you argue this way, this is a
debconf abuse (there is another operating system which likes to prompt
far too many issues). The Unix way is to write good docs, goods NEWS,
good logs. If something does not work as expected, I want to get solid
information. But I do not want info like "This might break (or might
not)".=20

Secondly as I mentioned above, I do adminster lots of machines. So
your question will *never* be seen by the users (they don't care. If
something is not working, I have to fix it anyhow). So your audience
is not reached. Instead your prompt is going to anoy me when I start
upgrading all the machines from Woody to Sarge (this report was done
on a private testing machine).

> > If the answer is no (which I doubt) then please include some scheme to
> > detect if X is actually running (not installed, really running) before
> > asking this question. Preferably, if TERM=3Dxterm or something similar,
> > so if the user is already on the console, it can be skipped as well.
>=20
> It's not as simple as checking TERM=3Dxterm.  (For one thing, there are
> lots of terminal emulators out there and they use different
> identifiers; for another thing, running inside 'screen' masks all trace
> from the process environment that it was invoked inside X.)  There is a
> way to tell if we're in X, which gpm used to use at upgrade time.  I'll
> see if I can find out exactly why the previous maintainers felt the
> need to stop relying on this check, but IIRC, it was because it was
> unreliable.

Ok, this was just a quick suggestion by me, I do not do a good
research on this.

>           *          *          *
>=20
> > The next question is completely unnesessary. Of course remember the
> > setting, otherwise I can run dpkg-reconfigure on it!
>=20
> I've never been comfortable with this second question either.  I'll
> have to reread the bug report(s) that caused us to put it in.

Ok.

> Thanks for the report,

Thanks for the *quick* reply! (And for taking care of gpm in general,
it was really in a bad shape, maintenance while.

Greetings

       Helge


--=20
Helge Kreutzmann, Dipl.-Phys.               Helge.Kreutzmann@itp.uni-hannov=
er.de
                       gpg signed mail preferred=20
    64bit GNU powered                  http://www.itp.uni-hannover.de/~kreu=
tzm
       Help keep free software "libre": http://www.freepatents.org/

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB37ZpRsxcY/MYpWoRAspAAJ9KtR8wYkmX6GQ6dTVQFbbKtXBlzQCgppvA
0hSkOzVllG21og171y9fLvk=
=9V1i
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--