[kde-freebsd] X related scripts in Xclients ports

[Lauri Watts]

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 that 
enough chocolate or some good solid arguments can sell me on changing my 
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 being 
run out of ttys - so clashes or double dipping on the case of upgrades is 
less of an issue there, but for xdm and kdm, while I know some people have 
always run them out of an rc script, the traditional and documented way has 
long been ttys.   

The note that there is a race condition here worries me very much.  I wonder 
what happens for instance, on an upgrade.  What will be the result if say, 
both /etc/ttys and rc are trying to start kdm (on the same tty no less).    
What if they are both starting it but on different ttys?  What if one is 
trying to start xdm, and the other is starting kdm?   What if people still 
have the existing gdm script around, and forget to remove it?  What if (and 
hey, I've seen this kind of thing before) ttys is starting xdm, kdm is set in 
rc.conf, *and* the old gdm script is still around :)

I can totally see this kind of situation arising, if people glance at the 
instructions during an upgrade.  Any instructions to use this new way, would 
have to be very clear that if you do use it, you must disable it from ttys.   
What if (for whatever reason, even just habit) people want to continue to run 
it out of ttys? Will we continue to support this? 

Even with clear instructions, we have to bear in mind users will still ignore 
them (or miss it entirely, kdebase spewing a pkg-message in the middle of a 
portupgrade, or a -DBATCH'ed compile of KDE or X, we already know people miss 
those messages all the time).   

Can the scripts be made to check ttys, and if there is an entry there already, 
bail immediately?  Doesn't rc provide the ability to only run things 
dependent on others, so can they be made to run only after ttys has been 
dealt with completely?  Can they check if any dm is already running (but only 
on that tty) and bail if so? Should we run everything out of /usr/X11R6/etc 
or /usr/local/etc instead of /etc - but then, how do we reconcile the fact 
that g/k/w/xdm all should be PREFIX safe, and for some of them, either of the 
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 
the issues it will cause to be acknowledged (or better, dealt with).  I'd 
prefer to be very very cautious on such a change, because we already all know 
a broken DM can effectively lock an inexperienced user out of their machine 
well enough they can't even come ask for help. 

Regards,
-- 
Lauri Watts
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20041115/204e6919/attachment.bin