Red Hat Bugzilla – Bug 477336
[freefont] Please convert to new font packaging guidelines
Last modified: 2009-03-24 14:47:48 EDT
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:
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 redhat.com
To help packagers manage the transition to the new guidelines, we've published the following FAQ
Created attachment 328799 [details]
Can you comment on this updated spec? Not really sure what the appropriate font name for this package is.
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.
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)
Adding myself on the CC list since my package gramps requires freefont.
Adding CC for slingshot.
Any help on this would be greatly appreciated. I'm pretty busy at the moment, and this is low on my personal priority list.
Maybe Jeffrey or Jon can step in as co-maintainers since their packages depend on yours?
I may be able to get to this next week.
Created attachment 331334 [details]
Nicholas, how does this look?
(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
Oh, is that all? ;) I'll get started.
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.
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.
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)
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?
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 :(
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.
(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.
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.
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
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?
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
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
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?
That way the only packages ending in -fonts in the repo are packages that actually contain font files
gnu-free-fonts has replaced freefont in rawhide.
Reminder to Nicolas and Orion to update cinepaint, plplot and ftgl-utils.