Modular X ramblings

[Brian Gerst]

Mike A. Harris wrote:
> Brian Gerst wrote:
>> - XFS didn't automatically restart, I had to manually start it.
> 
> The xfs rpm scripts have been updated recently with many changes.  One
> of the changes, was to have it check to see if it is upgrading from
> monolithic X to modular X or not, and if it is, to force a "restart"
> in the initscript.  If it is just modular to modular, then it does
> a "reload" instead.
> 
> It's possible the script is buggy though. It hasn't had a lot of testing
> yet.  Also, I'm open to suggestions for how to improve the "upgrade
> xfs package" situation.  Here are some concerns to consider:
> 
> 1) When xfs is restarted, the connection with the X server is broken,
>    so apps using core fonts can no longer find fonts.  While xset can
>    be used theoretically to re-establish a link to the X server, the
>    initscript has no idea wether the X server is :0, :1, :8, or all 3.
>    There is no "clean" way to have the connection re-established.
> 
> 2) Using "reload" causes it to reload the config file instead of
>    restarting, but then you are still using the old xfs server, not
>    the new one.  Also, the old one is unable to find it's config file
>    after upgrade, so must be restarted anyway.
> 
> 3) If an xfs security update goes out, the way things are now, you have
>    to manually restart xfs, as it wont get restarted otherwise.  That is
>    kindof bad, but it's the way it is right now to avoid disconnecting
>    xfs from the X server.
> 
> I'm open to hear suggestions if anyone has some for how we can solve
> these problems.
> 
> One thing I'd like to address before anyone does respond with
> suggestions though ...
> 
> When these type of problems arise with xfs, inevitably someone will
> eventually say "get rid of xfs, and just use the X server to serve
> the fonts directly and the problem is solved".  While that sounds
> very attractive in a once sentence email or IRC statement, in the
> real world, there are hundreds of thousands of deployed systems out
> there, and migrating away from xfs to using the X server would have
> to be performed rather smoothly on OS upgrades.  Getting the
> nuances of that correct is more complicated than one might think.
> 
> Also, chkfontpath currently configures the fontpaths into the xfs
> font server, and does not have any logic to do this with the X
> server.  We would _have_ to update chkfontpath to be able to handle
> the X server as well, yet still be able to do it with xfs for
> systems out there that _do_ want to still use xfs.  So ultimately,
> we still end up supporting xfs, only we now have to re-engineer
> a bunch of legacy code (chkfontpath) which is rather fragile to
> begin with, and make everything work without breaking systems
> out there beyond recognition.
> 
> Even if we were to do this, we do not really gain any new
> functionality at all, despite how much effort would be put into
> implementing and testing it all.  Also, we would be changing
> something that more or less "just works" most of the time, and
> has been done this way for 8 years or more.  Making such a change
> with no real visible gains is a big waste of time, energy and
> manpower that would be taken away from other possible projects
> that could have been done instead, which have real world benefits.
> 
> The reason I'm going into this level of detail in this email, is
> more or less to cut the conversation off before it starts, as it
> comes up every time xfs problems are mentioned, and the bottom
> line never changes.  xfs is a necessity that we have to live with,
> so we have to fix it if it breaks, as that is the least costly
> way to keep core fonts support working.
> 
> </diatribe> ;o)

In my case, I had shut down X and did all the upgrades from text 
console, so reconnecting xfs and the X server was not the issue.  The 
scripts simply failed to "service start xfs".

--
				Brian Gerst