Red Hat Bugzilla – Bug 59334
RFE: 'chkfontserver' mode for chkfontpath
Last modified: 2007-04-18 12:39:47 EDT
Description of Problem:
I can't convince chkfontpath to add a font path during a kickstart installation:
it is to an NFS-mounted directory. I should be able to force it to add it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. mkdir /tmp/newdir
2. chkfontpath -a /tmp/newdir
Won't add it.
Should add it, or tell me to supply an extra parameter if I'm sure (like --force).
That's not the way that chkfontpath works Tim. ;o)
or: rpm -q --scripts anyfontpackage
I'd tell ya, but... give a man a fish.... teach a man to fish...
Mike, it used to work that way, and now my kickstart script is broken, as is
anyone else's who used chkfontpath in %post.
How do I add a font path in a kickstart %post now then?
Read the manpage. Bugzilla is not a tech support forum, and chkfontpath
is working as documented.
But as a result, this change in behaviour means that NFS-mounted font paths can
no longer be set up during a kickstart installation.
If this isn't a chkconfig bug, please tell me which component it should be filed
I am mistaken: 7.2 acted the same way and apparently I didn't notice.
The correct way to give fonts to a new kickstart installation, as you pointed
out, is to configure xfs to use an alternate server. This looks like it's
fairly easy to do with the current chkfontpath code (perhaps with a --server
flag, or with a symlink named 'chkfontserver'). So, I'll change this into an
enhancement request for that.
Ok, that sounds fairly reasonable. I'm going to defer this for later
when I get a chance. I've got plans for integrating stuff like this
into the new config tool also.
I will investigate adding an option to supply a separate font server after
the existing 1.9.8 in rawhide has been tested a bit. I doubt many people
would use such an option though in practice.
I am quite leary though of adding a --force option, as chkfontpath was
made specifically for rpm package installation, and should be as robust
as possible for that task. Font installation has always been a huge
PITA, and there are lots of opportunities for screwups, and that can
result in a bad user experience, and lead to higher incidence of tech
support issues, and needless bug reports. I definitely do not want people
using fonts over NFS or any other networked filesystem if possible, as
a downed network can make the entire X server and all apps block forever.
Any font path should IMHO exist when chkfontpath is installed. If it doesn't,
that indicates some kind of extremely specialized corner case, and IMHO,
that can be handled by a sysadmin on a case by case basis, or by writing a
script to automate their broken desires themselves.
Also, most apps are going to Xft now, so as time goes on, xfs becomes more and
more unnecessary. I'd like to remove it at some point, although that wont
probably occur for a long time yet.
I'll poke at adding the alternative-servers option though.
Just scrolling through old bugs/requests and found this one. My
current thoughts about this are that the feature is still reasonable,
but not really super-useful to the majority of the userbase, in
particular because most applications now use Xft clientside fonts
It's not likely to ever be a Red Hat priority for myself to implement
this feature in chkfontpath, so I'm going to close this as "WONTFIX"
for now. If you (or anyone else) still wants this feature in
chkfontpath however, feel free to implement it and submit a patch
for it and reopen the bug for consideration.
It might even be a good idea to make chkfontpath a sourceforge
project or something in case people would like to further extend
it in other ways. I'm the upstream maintainer only via assignment,
rather than personal interest for the codebase, and the limit
of my involvement in the code will likely be limited to fixing
security bugs or crashes. If anyone else would like to stand
up as the official new "chkfontpath" maintainer, please speak up.
Setting status to "WONTFIX", pending volunteers or patches.