Bug 477336

Summary: [freefont] Please convert to new font packaging guidelines
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: freefontAssignee: Orion Poplawski <orion>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fonts-bugs, gwync, jeff, orion, petersen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-24 18:28:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 486977    
Bug Blocks: 477044, 477471, 477473, 480457, 480473    
Attachments:
Description Flags
freefont.spec
none
New spec none

Description Nicolas Mailhot 2008-12-20 17:15:58 UTC
After more than a month of consultation,
feedback and tweaking new font packaging guidelines have been approved
by FESCO.

http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
http://fedoraproject.org/wiki/Fedora_fonts_policy_package
http://fedoraproject.org/wiki/Simple_fonts_spec_template
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

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 redhat.com

Comment 1 Nicolas Mailhot 2009-01-11 15:19:09 UTC
To help packagers manage the transition to the new guidelines, we've published the following FAQ

http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ)

Comment 2 Orion Poplawski 2009-01-12 23:07:41 UTC
Created attachment 328799 [details]
freefont.spec

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 23:30:06 UTC
You need to use the %_font_pkg macro
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#What_is_a_compliant_font_.28sub.29package.3F

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
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#How_should_I_name_my_fonts_.28sub.29package.28s.29.3F

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 18:36:36 UTC
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
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29

— 2009-01-06: exact splitting rules
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

(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 14:53:59 UTC
Adding myself on the CC list since my package gramps requires freefont.

Comment 6 Gwyn Ciesla 2009-01-20 17:30:42 UTC
Adding CC for slingshot.

Comment 7 Orion Poplawski 2009-02-04 21:37:57 UTC
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 21:50:41 UTC
Maybe Jeffrey or Jon can step in as co-maintainers since their packages depend on yours?

Comment 9 Gwyn Ciesla 2009-02-06 18:47:05 UTC
I may be able to get to this next week.

Comment 10 Gwyn Ciesla 2009-02-09 17:03:40 UTC
Created attachment 331334 [details]
New spec

Nicholas, how does this look?

Comment 11 Nicolas Mailhot 2009-02-14 21:44:19 UTC
(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
http://fedoraproject.org/wiki/Packaging:FontsPolicy#Naming
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#What_if_the_new_naming_guidelines_require_me_to_rename_my_source_package.3F

2. build from the sfd sources upstream publishes
http://fedoraproject.org/wiki/Packaging:FontsPolicy#Building_from_sources

3. add a few fontconfig rules
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#The_fontconfig_stuff_the_font_guidelines_suggest_seems_complex._Can_I_skip_it.3F

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)
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#Can_I_re-indent.2Fre-order_the_fonts_packaging_template.3F

5. remove the "Requires:  fontconfig". It is contrary to packaging guidelines
http://fedoraproject.org/wiki/Packaging:FontsPolicy#Install-time_dependencies

6. probably be more conservative with provides
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#Do_I_need_to_Provide_my_old_package_names.3F

7. use -compat as metapackage if you need one
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#But_my_old_package_is_replaced_by_several_new_packages.21

8. use nice names for your subpackages via -n as suggested by the templates
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#What_font_packaging_changes_are_needed_with_post-1.13_fontpackages.3F


Piece of cake :p

Comment 12 Gwyn Ciesla 2009-02-17 19:24:34 UTC
Oh, is that all? ;)  I'll get started.

Comment 13 Gwyn Ciesla 2009-02-17 19:24:44 UTC
Oh, is that all? ;)  I'll get started.

Comment 14 Nicolas Mailhot 2009-02-18 19:31:50 UTC
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:
http://fedoraproject.org/wiki/Releases/11/Schedule

A week of this month will see the Fedora 11 mass rebuild, that will load the build farm:
http://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild

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.
http://fedoraproject.org/wiki/Features/AutomaticFontInstallation

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.
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29

Comment 15 Gwyn Ciesla 2009-02-23 14:57:39 UTC
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 15:32:36 UTC
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 15:40:47 UTC
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 15:53:26 UTC
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 16:12:02 UTC
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 17:06:05 UTC
(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 17:18:18 UTC
repoquery gives me:
moodle-0:1.9.4-1.fc10.noarch
cinepaint-0:0.22.1-10.fc10.i386
plplot-0:5.9.0-2.svn8752.fc10.i386
gramps-0:2.2.10-1.fc9.noarch
ftgl-utils-0:2.1.2-8.fc9.i386
slingshot-0:0.8.1p-1.fc8.noarch
gramps-0:3.0.4-1.fc10.noarch
cinepaint-0:0.22.1-7.fc9.i386

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 18:41:09 UTC
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 18:50:39 UTC
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 19:05:50 UTC
IIRC freefont has several font families inside

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

And users need to be upgraded from
freefont
to
gnu-free-fonts-compat
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
http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#Can.27t_I_use_my_old_package_name_instead_of_a_-compat_subpackage.3F

But I've clearly failed

Comment 25 Gwyn Ciesla 2009-02-23 19:15:01 UTC
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 19:25:11 UTC
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 18:28:59 UTC
gnu-free-fonts has replaced freefont in rawhide.

Comment 28 Gwyn Ciesla 2009-03-24 18:47:48 UTC
Reminder to Nicolas and Orion to update cinepaint, plplot and ftgl-utils.