Shipping fonts in Fedora (FAQ)

This page is intended to help packagers manage existing or future packages that embed font files. It was written at the occasion of the Fedora 11 fonts packaging guidelines change and answers most questions asked during the subsequent distribution-wide fonts audit and repackaging.

Is this page a Fedora guideline?

Even though this page is not itself an official Fedora guideline, it was written to explain the rationale behind our current guidelines, and should not conflict with them. In case of conflict the guidelines pages always take precedence.

What is a font file?

For the purposes of this page a font file is a file using the .ttf, otf, .ttc, .pfa, .pfb or pcf extensions.

What does Fedora require of me?

Fedora guidelines require packaging of every font file in the distribution in a font package or subpackage complying with our fonts packaging guidelines.

Do I need to change my package in stable releases in addition to Rawhide/devel?

You should only perform fonts guidelines conformance changes of existing packages in Rawhide, unless you identify a licensing problem that needs to be taken care of in all branches.

Can I import my new package in stable releases in addition to Rawhide/devel?

Importing new packages will work in all branches. Our guidelines are compatible with the font stacks available in all our current supported releases.

What is a compliant font (sub)package?

• A guidelines-compliant font (sub)package contains a single font family, packed with the %_font_pkg rpm macro, and no other material (except for eventual directory ownership and licensing or other documentation files).

• It is named according to our naming guidelines for fonts.

• It is referenced in the appropriate comps group.

• It has a page in the wiki we can reference in release notes. To create such a page use this template.

What is this font family thing?

• A font family corresponds to one entry in GUI font lists. For example, DejaVu Sans, DejaVu Serif and DejaVu Sans Mono are three different font families.
• A font family is subdivided in faces or styles. DejaVu Sans Normal, DejaVu Sans Bold, DejaVu Sans Condensed Italic are three faces of the DejaVu Sans font family.
• A font-metadata aware tool such as gnome-font-viewer or fontforge can be used to check the font family name and the font face/style declared by a font file.

How many font files can I put in a font (sub)package?

You can put as many font files in a font (sub)package as you want, as long as they correspond to the same font family. If your srpm includes files associated to different font families, you need to create one subpackage per font family.

See also our official font package splitting guidelines and this other question.

I can not comply, the tools my package uses force a specific font file installation!

Tools have bugs and limitations and this has never been a good reason to ignore distribution guidelines. You are responsible for your packaging and all the scripts and other tools involved in this process. If their operational mode conflicts with Fedora guidelines it's your responsibility to report the problem upstream to get it fixed, and work around the problems in your package in the meanwhile.

But my application crashes if I remove the font file(s)!

Then add dependencies on the guidelines-compliant font (sub)packages that provide the files you need, and either patch your application to look for them here or add symlinks with the filenames it expects in your package. See also this question.

Where should my fonts symlinks point?

A properly packaged font file will be installed in a subdirectory of %_fontbasedir. %_fontbasedir is defined by the fontpackages-devel package.

Should I use package name or file name dependencies?

It seems package names are preferred right now.

My dependency does not work in Rawhide, I'll try later!

Many font packages were reorganised in Rawhide during the Fedora 11 cycle so dependencies on pre-Fedora 11 package names are likely to fail. It won't get better later, just check the package names in Rawhide and adapt your package.

Why should I bother, my font use is limited/private/controlled/hidden/etc?

Bundling of font files falls into one of the following categories:

• private copies of font files already packaged in the distribution. Since fonts are bulky and compress poorly, you're wasting precious Fedora and user resources (bandwidth, mirror/disk space, etc). Also, application authors tend to copy fonts once and forget about them, so your copies are unlikely to be up to date, and will miss the fixes present in the dedicated Fedora font package.

• private copies of font files that could be packaged in Fedora, but aren't yet. This is the right time to package those fonts properly so your application is not the only one benefiting from them. No font cant be assumed beforehand not to be useful to someone else.

• private copies of font files that could not be packaged in Fedora, usually for legal reasons. You need to remove those at once as they are just as dangerous hidden inside a package as they would be exposed in a dedicated package.

Basically there is no good reason to pack fonts in non-font packages, and lots of drawbacks, which is why our guidelines are written the way they are. The deeper a font file is hidden inside an application the more likely it is to have escaped auditing so far and thus to present problems.

How can I check if my fonts present a legal risk?

You can't without identifying the fonts and tracing their source and licensing, which is the hard part of packaging fonts. Once you've done it packaging the fonts properly is only a little step, that will get you a review by people with more fonts licensing experience than you.

Do not assume the licensing of your fonts is the same as the rest of the package. It is almost never the case (besides software licenses do not apply well to fonts anyway).

How can I identify a font file?

When it works the gnome-font-viewer command will tell you the font family name declared by a file, its style/face, and some copyright information. The fontforge font editor may provide more complete info if necessary.

Use this information to check if the font is already packaged, and if not what the actual font upstream is and if it is suitable for packaging (web search engines are your friends).

How can I check if a font file is already available in the distribution?

If you're lucky your project didn't rename the font files and a simple repoquery on rawhide will find other packages that include them:

$ repoquery --repoid=rawhide -f '*DejaVuSansMono.ttf'
dejavu-fonts-sans-mono-0:2.28-1.fc11.noarch

You need to have the rawhide/fedora-devel repository configured and enabled for this command to work.

Also, repoquery won't distinguish between actual files and symlinks. When a font file is symlinked in several packages you need to look inside them to check which one ships the symlink target.

Unfortunately font file renaming is common, so repoquery won't always be enough. In that case you need to look inside the files themselves to know their content. Once you've identified a font a yum or web search will help you find eventual packages already shipping it.

What if my package bundles Bitstream Vera, Arev, DejaVu LGC or another Bitstream Vera font derivative?

In that case it is a good idea to replace the font files with symlinks to the corresponding DejaVu (full) packages. DejaVu (full) is the most complete fork of Bitstream Vera. It should include all the material present in Vera and its other derivatives, plus multiple fixes. Since we install the DejaVu (full) packages by default, dependencies on them will usually not pull in new packages on user systems.

What if my package bundles FreeSans, Linux Libertine, Droid or Liberation fonts?

Those are all general-purpose fonts. Replacing them with symlinks to the corresponding DejaVu (full) packages is usually the best solution, as the DejaVu (full) packages are our default general-purpose font set.

Nevertheless, do check with upstream if it had a specific reason to bundle those particular fonts (other than using the first general-purpose fonts on hand).

What if my package bundles a modified version of an existing Fedora font?

Assuming the modifications complied with the original font license and that you need them you can create a separate (sub)package for this font variant. fontconfig can manage several versions of the same font.

Though it's much better to convince the upstreams working on the same font to work together, or at least use different font names for each of the fork.

What if my package bundles the same font in several different formats?

If your application needs all those different formats, and you can not consolidate on a single one, you should probably package each different format in a separate (sub)package, so applications that do not have this limitation can only install one of them.

But I really do not want to take part in this fonts packaging business!

You're right that most packagers should not have to bother about font problems. And, actually, they don't! Any application that uses fontconfig will discover automatically where the fonts its author wanted are on system, and fallback transparently without crashes or breakage to other fonts if they're not present. Our fontconfig-aware packages do not need to bundle font files, symlinks, or dependencies on font packages.

If your upstream bundles specific font files, it is not using fontconfig. This will be a problem for you as fontconfig is the main *nix font system and the only one Fedora does heavy QA on. Alternatives are very prone to failure, each one of which will result in a bug open against your package.

Save yourself some work and convince your upstream to use fontconfig instead of other font discovery methods. And since fontconfig is a low-level library, upstream will usually want to use it through a higher-level library such as pangocairo.

Is there a simpler way?

See here.

I activated fontconfig in my application, should I remove font package dependencies? That feels unsafe!

You do not need any special font package dependency or symlink in a fontconfig-aware application. fontconfig is a very resilient system and will only fail if there is no font at all on-system that provides the glyphs needed to render your text. And in that case it will just not display text instead of crashing. Besides the fonts comps group is part of the default Fedora base install and should provide enough fonts to display most world scripts.

However, if your application has a preference for the style or metrics of a particular font, you can add a dependency on it to make sure it is installed and fontconfig does not have to fall back on another font.

But what if the fonts needed by a script are not installed?

Then Fedora will prompt users to install them. No need to add a specific dependency to your package.

The fontconfig stuff the font guidelines suggest seems complex. Can I avoid it?

There are good and simple commented fontconfig templates in the fontpackages-devel package. They only require you to fill in your font name and its category (so fontconfig and CSS aliases just work). So adding a fontconfig file should really be trivial (don't forget to send it to the font usptream for inclusion afterwards). We also have a wiki documentation page on the subject. Adding a goof fontconfig ruleset to your package would greatly enhance your user experience.

Nevertheless, this part is optional in the guidelines, to take into account the fonts which are already configured in the upstream fontconfig ruleset.

Can I just put all my fonts in a -fonts subpackage?

No, our actual requirements are deeper than that. Just moving font files in a separate subpackage, without making this subpackage comply with guidelines, is useless.

How should I name my fonts (sub)package(s)?

See requirements.

But my package has always worked this way!

Fedora fonts handling has long-standing problems but is slowly getting fixed. Please contribute to this fixing by bringing your package into line.

But other distributions do not bother!

Fedora is not other distributions. It is intended to lead[…] the advancement of free, open software and content.

This is too much work!

The amount of work necessary to make a package conform to our font guidelines is usually proportional to the amount of problems in a particular package, so if there is a lot of work to do that indicates a problem package we should really not ship in its current state.

Getting new font packages reviewed is going to take ages!

Packagers that follow our font packaging workflow get reviewed by a dedicated team in days, and will get merged just as fast if the submitter is responsive to the review comments.

How can I get a new font package included in Fedora/OLPC/EPEL?

Just follow the process outlined here.

The %_font_pkg macro is forcing choices on me!

This is the intent. We added this macro to purge all the custom font scriptlets in the distribution, since the variations packagers introduced almost invariably produced unforeseen bugs.

Where is the rest of the subpackaging bits in spectemplate-fonts-multi.spec?

The %_font_pkg macro is taking care of this for you.

What happened to the fc-cache scriptlets listed in previous guidelines?

The %_font_pkg macro is taking care of this for you.

Where are the %files sections of my font (sub)packages?

The %_font_pkg macro has an integrated %files section. It starts in the macro itself and continues till the beginning of the next rpm section. You can add additional content to a (sub)package created with %_font_pkg by listing it after the %_font_pkg call line.

rpmbuild complains of font files being listed twice!

You probably listed the font files in a manual %files section instead of letting %_font_pkg take care of them for you. Read this.

rpmbuild fails with Package does not exist: %post fonts[-…]-fonts

You've been bitten by this change. The fix is documented here.

The templates must be wrong, rpmbuild crashes/fails!

It is unfortunately rather easy to make rpm crash when using macros. The documented syntax works and has been tested on dozens of packages. Trying to change it, however, will likely lead you to rpm crash land.

Try to not deviate from the documented syntax:

• for new packages, make sure you've added all the elements required in the templates.
• when adaptating existing packages, make sure you've removed all the old %files %post %postun etc parts that may conflict with the new templates.
• in all cases, check you've not cut and pasted the same subpackage name twice. rpm really does not like that

I have unowned directories!

You should not. If you follow our guidelines carefully, the font (sub)packages should own their font directory (if there is a single font family in the srpm) or depend on a common subpackage that owns it (if there are several font families in the srpm, resulting in multiple font packages).

If I make my font subpackage noarch koji crashes!

Don't do that. Our infrastructure is getting fixed to support this case, but can not handle it (yet).

rpmlint complains of absolute symbolic links!

The future of this particular warning is being discussed by FPC right now (ideally rpmbuild should convert absolute symlinks to relative ones transparently). You can ignore it for now.

No font (sub)package is created in mock/koji!

You've forgotten to include the template (build)requires on fontpackages-*.

How about console/X11 core fonts/TEX/ghostscript fonts packaging or registration?

No one cared enough about those so far to write corresponding Fedora packaging guidelines. You are free to add whatever you want about them to your packages, as long as it's not in the guidelines-compliant font (sub)package.

To add the overlay corresponding to another font system to a Fedora fonts (sub)package, create a separate (sub)package that contains this overlay and depends on the corresponding fonts guidelines-compliant (sub)packages (and not the reverse).

Fedora fonts are broken anyway, my application crashes!

A crashing application is a symptom of an application not converted to fontconfig yet. Save yourself some grief and have your upstream/ISV convert it to fontconfig now.

Since the vast majority of our applications started using fontconfig quite long time ago, Fedora does not install the complete legacy X11 core fonts set by default anymore. If your application or package depends on it it has to request the associated packages explicitly.

Why all naming churn, font packages got renamed twice?

FPC unexpectedly refused to approve a proposal that put into writing the package naming rules for fonts we had been using in the past years. Those rules were implied by packaging macros and templates FESCO and FPC had previously approved.

The revised naming rules adopted after taking into account the changes requested by FPC required renaming of several font packages, including recently created ones.

If you'd already complied with previous fonts packaging guidelines, you only need a small additional fix.

Why did the %_font_pkg macro behaviour change after fontpackages version 1.13 ?

See here.

Why did the multi-fonts-families template change after fontpackages version 1.13 ?

See here.

What font packaging changes are needed with post-1.13 fontpackages ?

Fonts packaging changes required by the new FPC packages naming rules for fonts

Case	Example, for the foo font family
	Old pattern	New pattern
Single-font-family fonts packages	No changes
Multi-font-families fonts packages	%package foo […] %description foo	%package -n %{fontname}-foo-fonts […] Obsoletes: %{name}-foo < thisversion-thisrelease %description -n %{fontname}-foo-fonts
Fonts subpackages of non-font source packages	%package fonts-foo […] %description fonts-foo […] %_font_pkg -n fonts-foo …	%package foo-fonts […] %description foo-fonts […] %_font_pkg -n foo …

Do I need to Obsolete my old package names?

Yes, you do need to obsolete your old package names to provide Fedora users a working upgrade path. When one of your new (sub)packages replaces one or several previous packages, you only need to add:

%package -n %{fontname}-foo-fonts
[…]
Obsoletes: myold(sub)packagename1 < thisversion-thisrelease
Obsoletes: myold(sub)packagename2 < thisversion-thisrelease
[…]

%description -n %{fontname}-foo-fonts

…to the metadata of your new (sub)package.

But my old package is replaced by several new packages!

When implementing our packaging guidelines requires the splitting of one package into several new (sub)packages things are a bit less easy. In that case you need to create a -compat subpackage corresponding to the (sub)package that was split, that obsoletes the old (sub)package and requires the new split (sub)packages. Please make it clear in its description that this is a utility package people should not depend on that will be eventually retired. Do not declare this compat package in comps.

%package compat
[…]
Obsoletes: myold(sub)packagename1 < thisversion-thisrelease
Obsoletes: myold(sub)packagename2 < thisversion-thisrelease
[…]
Requires:  mynew(sub)packagename1 = thisversion-thisrelease
Requires:  mynew(sub)packagename2 = thisversion-thisrelease
[…]

%description compat
This package only exists to help transition <mypackage> users to the new
package split. It will be removed after one distribution release cycle, please
do not reference it or depend on it in any way.

DejaVu, Bitstream Vera and MGOpen use this upgrade path pattern.

Can't I use my old package name instead of a -compat subpackage?

If you use your old package name you do not communicate to your users this is a temporary transitional metapackage to help upgrades. They'll keep referencing the old package name and even add more references to it, and you'll get stuck with it forever.

Plus, the existence of a metapackage with a -fonts naming similar to new packages but not following the new packaging rules is only going to confuse users.

Do I need to Provide my old package names?

Providing your old package names is not necessary to create working upgrade paths Providing old package names is useful if you have other packages that depend on your old package name and you don't want them to change. In any way Fedora packaging best practices are to clean up old Provides and Obsoletes after two releases, so those other packages will have to change eventually.

Thus, you have the choice between:

• doing a clean break, and having other packagers adapt now, when they'll blame the whole font audit and repackaging operation, or
• keep providing your old package names, till you eventually remove them, and people blame you because by this time they'll have forgotten about the operation.

You can check what package is depending on your old package names with the following command, if you have the rawhide repository configured and activated in yum:

repoquery --repoid=rawhide --whatrequires myoldpackagename

Whatever your decision it is polite to notify the maintainers of those other packages you've changed or going to change one of their dependencies. Please file the corresponding bugzilla tickets and make them block the audit tracker.

Exception
As an exception the default Fedora font set, DejaVu, will carry provides for its old names till just before Fedora 11 beta, to give people time to adapt. Packagers who followed previously published advice have therefore a few weeks to transition. The Fedora 11 beta will ship without the old DejaVu package names and maintainers who have not adapted their depending packages by then will experience breakage.

What if the new naming guidelines require me to rename my source package?

Follow the usual procedure to remove your current package from rawhide, and post a renaming review request for the new package.

For maximum efficiency this review request should:

• depend on the previous review ticket of your package,
• block the audit tracker,
• include the reference of the rel-eng ticket blocking your previous package and
• CC the fonts SIG bugs mailing list.

Renaming review are only required to check the sanity of the upgrade path, so they can be pretty quick.

If your font is referenced on our packaged fonts list, please do not forget to update its wiki page accordingly.

How can I check if my upgrade path work?

1. install your old packages on a Fedora system,
2. adapt your spec file and mock/koji-build the result,
3. copy your new packages to a local directory,
4. run createrepo on this directory,
5. point yum to it,
6. try a yum update.
7. if that fails, rpm -e whatever yum update installed and repeat from step 1.

You can also use:

rpm -qp --obsoletes mypackage

… to check the obsoletes declared by one of your new packages and,

yum list obsoletes

before the yum update to check what yum thinks about your new packages.

Why is the common subpackage in the multi-font-families templates named foo-fonts-common and not foo-common-fonts?

This subpackage is a normal utility subpackage with no fonts inside so there's no reason not to name it srpmname-common as usual (it's not a font package with a font family named Common inside).

What's the point of the common subpackage?

It's here to own the common directory font files are installed into, and to own other files common to all the fonts subpackages (documentation…).

How can I help test and QA the fonts packaging changes?

See Features/Repackaging_of_Fedora_fonts#How_To_Test.

I have other questions/who can help me?

If this page does not answer all your questions you can always ask for help on the Fedora fonts mailing list.

Notes:

Fonts in Fedora
The Fonts SIG takes loving care of Fedora fonts. Please join this special interest group if you are interested in creating, improving, packaging, or just suggesting a font. Any help will be appreciated.