Bug 477336 - [freefont] Please convert to new font packaging guidelines
[freefont] Please convert to new font packaging guidelines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: freefont (Show other bugs)
rawhide
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:
Environment:
Last Closed: 2009-03-24 14:28:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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, Jon 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
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 10:19:09 EST
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 18:07:41 EST
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 18:30:06 EST
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 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
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 09:53:59 EST
Adding myself on the CC list since my package gramps requires freefont.
Comment 6 Jon 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 Jon Ciesla 2009-02-06 13:47:05 EST
I may be able to get to this next week.
Comment 10 Jon 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
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 Jon Ciesla 2009-02-17 14:24:34 EST
Oh, is that all? ;)  I'll get started.
Comment 13 Jon 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:
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 Jon 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 Jon 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 Jon 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 Jon Ciesla 2009-02-23 12:18:18 EST
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 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 Jon 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
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 Jon 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 Jon Ciesla 2009-03-24 14:28:59 EDT
gnu-free-fonts has replaced freefont in rawhide.
Comment 28 Jon 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.