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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
