Bug 477336
Summary: | [freefont] Please convert to new font packaging guidelines | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> | ||||||
Component: | freefont | Assignee: | Orion Poplawski <orion> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | rawhide | CC: | 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: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 486977 | ||||||||
Bug Blocks: | 477044, 477471, 477473, 480457, 480473 | ||||||||
Attachments: |
|
Description
Nicolas Mailhot
2008-12-20 17:15:58 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) 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.
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. 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) 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]
New spec
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 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 Oh, is that all? ;) I'll get started. 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: 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 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: 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. 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 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 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. |