TOPIC: RPM PACKAGE MANAGER
Adding Microsoft Core Fonts to Fedora 19
6th July 2013While I have a previous posting from 2009 that discusses adding Microsoft's Core Fonts to the then current version of Fedora, it did strike me that I hadn't laid out the series of commands that were used. Instead, I referred to an external and unofficial Fedora FAQ. That's still there, yet I also felt that I was leaving things a little to chance, given how websites can disappear quite suddenly.
Even after next to four years, it still amazes me that you cannot install Microsoft's Core Fonts in Fedora as you would on Ubuntu, Linux Mint or even Debian. Therefore, the following series of steps is as necessary now as it was then.
The first step is to add in a number of precursor applications such as wget for command line file downloading from websites, cabextract for extracting the contents of Windows CAB files, rpmbuild for creating RPM installers and utilities for the XFS file system that chkfontpath needs:
sudo yum -y install rpm-build cabextract ttmkfdir wget xfs
Here, I have gone with terminal commands that use sudo, but you could become the superuser (root) for all of this and there are those who believe you should. The -y switch tells yum to go ahead with prompting you for permission before it does any installations. The next step is to download the Microsoft fonts package with wget:
sudo wget http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec
Once that is done, you need to install the chkfontpath package because the RPM for the fonts cannot be built without it:
sudo rpm -ivh http://dl.atrpms.net/all/chkfontpath
Once that is in place, you are ready to create the RPM file using this command:
sudo rpmbuild -ba msttcorefonts-2.0-1.spec
After the RPM has been created, it is time to install it:
sudo yum install --nogpgcheck ~/rpmbuild/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
When installation has completed, the process is done. Because I used sudo, all of this happened in my own home area, so there was a need for some housekeeping afterwards. If you did it by becoming the root user, then the files would be there instead, and that's the scenario in the online FAQ.
Ridding Fedora of Unwanted Software Repositories
4th November 2010Like other Linux distributions, Fedora has the software repository scheme of things for software installation and updating. However, it could do with having the ability to remove unwanted repositories through a GUI, only it doesn't. What you need to do instead is switch to root in a terminal using the command su - and enter your root user password before navigating to /etc/yum.repos.d/ to delete the troublesome [file name].repo file. Recently, I needed to do this after upgrading to Fedora 14 or yum wouldn't work from the command line, which is the way that I tend to update Fedora (yum -y update is the command that I use because it automatically does all installations unattended until it is finished doing what's needed). The offending repository, or "Software Source" as these things are called in the GUI, belonged to Dropbox and even disabling it didn't make yum operate from the command like it should, so it had to go. Maybe Dropbox hasn't caught up with the latest release of Fedora, but that can be resolved another day.
Adding msttcorefonts to Fedora
28th July 2009Once you have enabled the appropriate software repository, you can install the msttcorefonts (Microsoft TrueType core fonts like Arial, Times Roman, Verdana, Georgia, etc.) package on Debian and Ubuntu. With Fedora, it surprisingly isn't so straightforward. There is a recipe using the command line that worked for me, and I'm not going to repeat it here, so I'll leave you to go where I found it. In fact, it forms part of a wider unofficial Fedora FAQ that may be of more interest to you than solving this.
Update for Fedora 12 (2009-11-24):
You also need chkfontpath so the following needs doing before the final part of the command sequence, changing the filename as appropriate for your situation:
yum install xfs
rpm -ivh http://dl.atrpms.net/all/chkfontpath-1.10.1-2.fc12.i686.rpm
A fallback installation routine?
9th November 2007In a previous sustained spell of Linux meddling, the following installation routine was one that I encountered rather too often when RPM's didn't do what I required of them (having a SUSE distro in a world dominated by a Red Hat standard didn't make things any easier...):
tar xzvf progname.tar.gz; cd progname
The first part of the command extracts from a tarball compressed using gzip and the second one changes into the new directory created by the extraction. For files compressed with bzip use:
tar xjvf progname.tar.bz2; cd progname
The command below configures, compiles and installs the package, running the last part of the command in its own shell.
./configure; make; su -c make install
Yes, the procedure is a bit convoluted, but it would have been fine if it always worked. My experience was that the process was a far from foolproof one. For instance, an unsatisfied dependency is all that is needed to stop you in your tracks. Attempting to install a GNOME application on a KDE-based system is as good a way to encounter this result as any. Other horrid errors also played havoc with hopeful plans from time to time.
It shouldn't surprise you to find that I will be staying away from the compilation/installation business with my main Ubuntu system. Synaptic Package Manager and its satisfactory dependency resolution fulfil my needs well and there is the Update Manager too; I'll be leaving it for Canonical to do the testing and make the decisions regarding what is ready for my PC as they maintain their software repositories. My past tinkering often created a mess, and I'll be leaving that sort of experimentation for the safe confines of a virtual machine from now on...