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): chkfontpath-1.9.5-3 How Reproducible: 100% Steps to Reproduce: 1. mkdir /tmp/newdir 2. chkfontpath -a /tmp/newdir Actual Results: Won't add it. Expected Results: 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) man chkfontpath or: rpm -q --scripts anyfontpackage I'd tell ya, but... give a man a fish.... teach a man to fish... *runs*
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 under.
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 with fontconfig. 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. ;o) Setting status to "WONTFIX", pending volunteers or patches.