Foreword
This change is part of the list of cleanups discussed on the fonts and devel lists since november 2008. It is intended to make rules clearer for new and existing packagers, by rewording rules in a more succinct and imperative manner. Experience shows that too much leeway just results in packagers wasting time as they find new “interesting” ways to interpret the guidelines.
The change consists of the rewording one paragraph of our current font policy.
Previous wording
As noted in the Packaging Guidelines, Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.
Sometimes local groups publish a collection of fonts of different origins and different licensing in a single archive. In that case the interested packager SHOULD ask this upstream to break up its archive in different files. If upstream refuses the packager MAY base a single src.rpm on the collection archive, but he MUST make sure each bundled font set ends up in a different, appropriately licensed sub-package.
When a project is the upstream of several font families, which are all licensed the same way, and released on the same dates, in a single archive, the packager MAY create a single package. However the packager SHOULD consider splitting each font family in a different sub-package, so users can install only the font families they care about.
Multi-source packages are difficult to maintain and confusing to users. In addition:
- fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.
- multi-family packages force users to install fonts they may not care of or even like just to get the other fonts in the package.
As a rule, try to produce small simple user-friendly mono-family font packages that will be easy to maintain (you should however strive to group different faces of the same font family in the same package). Avoid grouping unrelated fonts in a single package.
Package layout of font packages
- Fonts released upstream in separate archives MUST be packaged in separate source packages (src.rpm), unless they belong to the same font family.
- Packagers SHOULD ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:
- fonts with other material such as application code, or
- different font families.
- As an exception, when a project is the upstream of several font families, which are all licensed the same way, and released on the same date, with the same version, the use of a common release archive is tolerated.
- Packagers MUST package each font family in a separate (noarch.rpm) (sub)package, notwithstanding on how they applied the previous source package (src.rpm) rules. The only admitted exceptions are:
- source packages that only include one font family and no other code or content (font documentation excepted), in which case a simple package is fine,
- font families which are designed to extend other font families with larger Unicode coverage (for example Arial Unicode, Droid Sans Fallback), in which case grouping the font family and its extension in a single (sub)package is acceptable.
- such cases should be notified to the fontconfig maintainer and the Fedora fonts list, so the font family split can be eventually hidden from users.
- historic Latin fonts which share a common designer, and are intended to be used together, as evidenced by their name (for example Liberation Sans, Liberation Serif and Liberation Mono). In that case splitting them in different subpackages or not is left to the packager discretion.
- fonts that use a format that bundles different font families in a single file.
- On the other hand, the different faces of a font family MUST be packaged together in a common (noarch.rpm) (sub)package, and not spread over different (sub)packages.
Rationale
As noted in the Packaging Guidelines, Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.
Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.
The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families.
Lastly, multi-font packages unnecessarily complexify font auto-installation.
Notes: