This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 477336 - [freefont] Please convert to new font packaging guidelines
[freefont] Please convert to new font packaging guidelines
Product: Fedora
Classification: Fedora
Component: freefont (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Orion Poplawski
Fedora Extras Quality Assurance
Depends On: 486977
Blocks: F11-new-font-rules 477471 477473 480457 480473
  Show dependency treegraph
Reported: 2008-12-20 12:15 EST by Nicolas Mailhot
Modified: 2009-03-24 14:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-24 14:28:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
freefont.spec (3.34 KB, text/plain)
2009-01-12 18:07 EST, Orion Poplawski
no flags Details
New spec (3.60 KB, application/octet-stream)
2009-02-09 12:03 EST, Gwyn Ciesla
no flags Details

  None (edit)
Description Nicolas Mailhot 2008-12-20 12:15:58 EST
After more than a month of consultation,
feedback and tweaking new font packaging guidelines have been approved

Package maintainers must now convert their packages in rawhide to the new templates.

The following packages have already been converted in rawhide and can
serve as examples if the templates published in the fontpackages-devel package are not clear enough:

❄ andika-fonts
❄ apanov-heuristica-fonts
❄ bitstream-vera-fonts
❄ charis-fonts
❄ dejavu-fonts
❄ ecolier-court-fonts
❄ edrip-fonts
❄ gfs-ambrosia-fonts
❄ gfs-artemisia-fonts
❄ gfs-baskerville-fonts
❄ gfs-bodoni-classic-fonts
❄ gfs-bodoni-fonts
❄ gfs-complutum-fonts
❄ gfs-didot-classic-fonts
❄ gfs-didot-fonts
❄ gfs-eustace-fonts
❄ gfs-fleischman-fonts
❄ gfs-garaldus-fonts
❄ gfs-gazis-fonts
❄ gfs-jackson-fonts
❄ gfs-neohellenic-fonts
❄ gfs-nicefore-fonts
❄ gfs-olga-fonts
❄ gfs-porson-fonts
❄ gfs-solomos-fonts
❄ gfs-theokritos-fonts
❄ stix-fonts
❄ yanone-kaffeesatz-fonts

FPC and FESCO were not consulted on splitting or renaming packages, nevertheless the new templates make it fare easier to manage subpackages, so you're strongly encouraged to split your packages along font family lines.

A mandatory rule about splitting will probably be submitted for approval before the F11 release.

Further information on fonts packaging changes will be published on fedora-fonts-bugs-list at
Comment 1 Nicolas Mailhot 2009-01-11 10:19:09 EST
To help packagers manage the transition to the new guidelines, we've published the following FAQ
Comment 2 Orion Poplawski 2009-01-12 18:07:41 EST
Created attachment 328799 [details]

Nicolas -

  Can you comment on this updated spec?  Not really sure what the appropriate font name for this package is.
Comment 3 Nicolas Mailhot 2009-01-12 18:30:06 EST
You need to use the %_font_pkg macro

I'm sure this will make your task easier and simplify your spec considerably

For examples, see the dejavu, vera, mgopen, abyssinica etc packages

As for the naming, my suggested guideline is

but FPC is discussing changes to it. spot has probably the best view on what the final rules are likely to be.
Comment 4 Nicolas Mailhot 2009-01-14 13:36:36 EST
FPC approved those two additional guidelines recently, please take them into account if you need to create or update a fonts package or subpackage:

– 2009-01-14: naming

— 2009-01-06: exact splitting rules

(packagers that can drop font files and just depend on an existing font package are not impacted)
Comment 5 Jeffrey C. Ollie 2009-01-17 09:53:59 EST
Adding myself on the CC list since my package gramps requires freefont.
Comment 6 Gwyn Ciesla 2009-01-20 12:30:42 EST
Adding CC for slingshot.
Comment 7 Orion Poplawski 2009-02-04 16:37:57 EST
Any help on this would be greatly appreciated.  I'm pretty busy at the moment, and this is low on my personal priority list.
Comment 8 Nicolas Mailhot 2009-02-04 16:50:41 EST
Maybe Jeffrey or Jon can step in as co-maintainers since their packages depend on yours?
Comment 9 Gwyn Ciesla 2009-02-06 13:47:05 EST
I may be able to get to this next week.
Comment 10 Gwyn Ciesla 2009-02-09 12:03:40 EST
Created attachment 331334 [details]
New spec

Nicholas, how does this look?
Comment 11 Nicolas Mailhot 2009-02-14 16:44:19 EST
(In reply to comment #10)
> Created an attachment (id=331334) [details]
> New spec
> Nicholas, how does this look?

This one looks better, however to completely convert freefont you should:

1. rename the base package to gnu-free-fonts

2. build from the sfd sources upstream publishes

3. add a few fontconfig rules

4. try to stay closer to the template by using the same declaration order and spacing lines (makes it so much easier to check in a diff tool)

5. remove the "Requires:  fontconfig". It is contrary to packaging guidelines

6. probably be more conservative with provides

7. use -compat as metapackage if you need one

8. use nice names for your subpackages via -n as suggested by the templates

Piece of cake :p
Comment 12 Gwyn Ciesla 2009-02-17 14:24:34 EST
Oh, is that all? ;)  I'll get started.
Comment 13 Gwyn Ciesla 2009-02-17 14:24:44 EST
Oh, is that all? ;)  I'll get started.
Comment 14 Nicolas Mailhot 2009-02-18 14:31:50 EST
This is a reminder for all the packagers that still have bugs open about adapting to font packaging guidelines there is only one month left before Fedora 11 beta:

A week of this month will see the Fedora 11 mass rebuild, that will load the build farm:

As already converted packages showed it is quite possible to make mistakes during the conversion. Please make releng and QA happy and don't wait till the last minute to do your changes (avoid pre-beta panic). If possible start before the mass rebuild so we don't burn cycles on incorrect packages.

The PackageKit enhancements stated for Fedora 11 assume fonts and font-using packages are sane (basically respect packaging guidelines). It is quite possible that not-converted packages will interact with the F11 font autoinstall feature in "interesting" ways.

We don't want that

There is extensive documentation on the wiki and most of your questions have likely already been answered there. Please do read the FAQ before making more work for the support team by asking questions answered there.
Comment 15 Gwyn Ciesla 2009-02-23 09:57:39 EST
From #11, I've done 1, 2, 5 and 6.  I could use assistance with 3, 4, 7 and 8, so I'll submit a review for the new package and set it blocking this bug.
Comment 16 Nicolas Mailhot 2009-02-23 10:32:36 EST
3. is mostly just filling the right template in  /usr/share/fontconfig/templates/
The feedback I have so far from the people who looked at them is that it was harder to decide to look at them than actually use them. Can't do a lot for the first part.

4. is mostly cosmetic

For 7 & 8 I'd be happy to clarify the doc or templates if you could tell me what you don't understand (very frustrating to write help and not know what part is wrong)
Comment 17 Gwyn Ciesla 2009-02-23 10:40:47 EST
Well, for 7, do I need a compat- package?  I don't think I do.  For 8, I already use -n in the %_font_pkg macro, is that sufficient?
Comment 18 Nicolas Mailhot 2009-02-23 10:53:26 EST
You need a compat package if you want to provide an upgrade path for users of the current package that upgrades to the full font set. Having the main package require the other packages is a no-go, it kills modularity

For 8 if you do not use -n in %package and %description as documented in the templates I'd be surprised if it built at all.

That still does not tell me what I should change in the doc to avoid the next packager making the same mistakes :(
Comment 19 Gwyn Ciesla 2009-02-23 11:12:02 EST
How does a compat subpackage doing the same thing *not* kill modularity?

8: But it does.  I'll have another look at the templates.

As far as doc changes, maybe it's just me, but I find concrete examples to be more illuminating that templates.  Could just be my learning style, but I had more luck understanding what needed to be done (or so I thought) by looking at the already-converted specs that at the templates.
Comment 20 Nicolas Mailhot 2009-02-23 12:06:05 EST
(In reply to comment #19)
> How does a compat subpackage doing the same thing *not* kill modularity?

Because nothing depends on the compat package, it can be removed, and new installes do not even see it exists

> 8: But it does.  I'll have another look at the templates.
> As far as doc changes, maybe it's just me, but I find concrete examples to be
> more illuminating that templates.  Could just be my learning style, but I had
> more luck understanding what needed to be done (or so I thought) by looking at
> the already-converted specs that at the templates.

The problem with concrete example is a "pure" package is rather uncommon and blind cut & pasting results in copying quirks.

But if you want to look at concrete converted packages, certainly there is no lack of them.
Comment 21 Gwyn Ciesla 2009-02-23 12:18:18 EST
repoquery gives me:

That need freefont.  Moodle and slingshot are mine.  Would it not be better to simply pull the band-aid off and fix all these right after freefont>gnu-free-fonts, and be done with it?

I wasn't suggesting copy/pasting, just reading for guidance.
Comment 22 Nicolas Mailhot 2009-02-23 13:41:09 EST
The point of a compat package is to kill the old name completely so packages depending on it adapt to the new font name now. I think that's the same thing you mean as pulling the band-aid (also the packagers of those should seriously consider why they depend on freefont and not one of our default fonts)

But first, freefont packaging need to be fixed
Comment 23 Gwyn Ciesla 2009-02-23 13:50:39 EST
Exactly! We both want that, I think, but what I'm getting at is, why is forcing packages to move from freefont to freefont-compat to gnu-free-fonts better than forcing packages to go from freefont to gnu-free-fonts?
Comment 24 Nicolas Mailhot 2009-02-23 14:05:50 EST
IIRC freefont has several font families inside

So package deps need to move from
gnu-free-foo1-fonts, gnu-free-foo2-fonts, etc

And users need to be upgraded from
that requires
gnu-free-foo1-fonts, gnu-free-foo2-fonts

A gnu-free-fonts package should never exist in the system or people will start adding deps on it

I've tried to explain this in

But I've clearly failed
Comment 25 Gwyn Ciesla 2009-02-23 14:15:01 EST
So instead of main package, subpackages for font families and a compat package, it's just the subpackages for font families and a compat package, so that there is not an RPM that matches the name of the SRPM?
Comment 26 Nicolas Mailhot 2009-02-23 14:25:11 EST
That way the only packages ending in -fonts in the repo are packages that actually contain font files
Comment 27 Gwyn Ciesla 2009-03-24 14:28:59 EDT
gnu-free-fonts has replaced freefont in rawhide.
Comment 28 Gwyn Ciesla 2009-03-24 14:47:48 EDT
Reminder to Nicolas and Orion to update cinepaint, plplot and ftgl-utils.

Note You need to log in before you can comment on or make changes to this bug.