From owner-freebsd-x11@FreeBSD.ORG Mon Nov 15 14:04:49 2004 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CDEE16A4CE; Mon, 15 Nov 2004 14:04:49 +0000 (GMT) Received: from mandarin.fruitsalad.org (pc117.net160.koping.net [81.16.160.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9CA043D2D; Mon, 15 Nov 2004 14:04:48 +0000 (GMT) (envelope-from lauri@kde.org) Received: from kurant.internal.hasta.se ([192.168.15.5] helo=kurant.fruitsalad.org) by mandarin.fruitsalad.org with esmtp (Exim 4.34 (FreeBSD)) id 1CThTM-000Gdf-3D; Mon, 15 Nov 2004 15:04:48 +0100 From: Lauri Watts To: kde-freebsd@freebsd.kde.org Date: Mon, 15 Nov 2004 15:04:32 +0100 User-Agent: KMail/1.7.50 References: <200411151151.33028.freebsd@redesjm.local> <200411151500.31461.andy@athame.co.uk> <4198AEC1.3020307@gmx.net> In-Reply-To: <4198AEC1.3020307@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8992962.MKtF8Wrray"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411151504.41066.lauri@kde.org> cc: freebsd-x11@freebsd.org cc: freebsd-gnome@freebsd.org Subject: Re: [kde-freebsd] X related scripts in Xclients ports X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 14:04:49 -0000 --nextPart8992962.MKtF8Wrray Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 15 November 2004 14:27, Michael Nottebrock wrote: > I think it would be wise to first take a look (and a testdrive) of Jose's > work before roundabout dismissing it. Although my first reaction is "I don't like it" you ought to know by now th= at=20 enough chocolate or some good solid arguments can sell me on changing my=20 mind. I guess I'm asking to be sold on this. > As the author of the kdm-stuff in the current kdebase port, I'm aware of > the flaws it has and how support-intensive it has been - Jose's doing work > on this in order to _work_ with this, so the support-question is indeed > interesting here. Also, gdm has been launched from an rc-script for quite > some time now, hence the POLA question isn't so clear cut - and depending > on how Jose's implementation actually looks like, users might never have = to > 'upgrade' to the rc-script way if they choose not to. I thought gdm was launched from an rc script because it doesn't support bei= ng=20 run out of ttys - so clashes or double dipping on the case of upgrades is=20 less of an issue there, but for xdm and kdm, while I know some people have= =20 always run them out of an rc script, the traditional and documented way has= =20 long been ttys. =20 The note that there is a race condition here worries me very much. I wonde= r=20 what happens for instance, on an upgrade. What will be the result if say,= =20 both /etc/ttys and rc are trying to start kdm (on the same tty no less). = =20 What if they are both starting it but on different ttys? What if one is=20 trying to start xdm, and the other is starting kdm? What if people still= =20 have the existing gdm script around, and forget to remove it? What if (and= =20 hey, I've seen this kind of thing before) ttys is starting xdm, kdm is set = in=20 rc.conf, *and* the old gdm script is still around :) I can totally see this kind of situation arising, if people glance at the=20 instructions during an upgrade. Any instructions to use this new way, woul= d=20 have to be very clear that if you do use it, you must disable it from ttys.= =20 What if (for whatever reason, even just habit) people want to continue to r= un=20 it out of ttys? Will we continue to support this?=20 Even with clear instructions, we have to bear in mind users will still igno= re=20 them (or miss it entirely, kdebase spewing a pkg-message in the middle of a= =20 portupgrade, or a -DBATCH'ed compile of KDE or X, we already know people mi= ss=20 those messages all the time). =20 Can the scripts be made to check ttys, and if there is an entry there alrea= dy,=20 bail immediately? Doesn't rc provide the ability to only run things=20 dependent on others, so can they be made to run only after ttys has been=20 dealt with completely? Can they check if any dm is already running (but on= ly=20 on that tty) and bail if so? Should we run everything out of /usr/X11R6/etc= =20 or /usr/local/etc instead of /etc - but then, how do we reconcile the fact= =20 that g/k/w/xdm all should be PREFIX safe, and for some of them, either of t= he=20 above is the wrong PREFIX. > So, please, let's be open-minded here (it's kind of weird that I of all > people have to write this, since I've been the ever-sceptic about this > whole topic before). I would simply like a clear explanation of what this would improve, and for= =20 the issues it will cause to be acknowledged (or better, dealt with). I'd=20 prefer to be very very cautious on such a change, because we already all kn= ow=20 a broken DM can effectively lock an inexperienced user out of their machine= =20 well enough they can't even come ask for help.=20 Regards, =2D-=20 Lauri Watts KDE Documentation: http://docs.kde.org KDE on FreeBSD: http://freebsd.kde.org --nextPart8992962.MKtF8Wrray Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBmLd4/gUyA7PWnacRAgVBAJ9HPJYMYkzsRiK5nOHb7+6wZU1mCwCgicut LqPIeMhVW8JA8WVyHly65vA= =w3ys -----END PGP SIGNATURE----- --nextPart8992962.MKtF8Wrray--