https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard – variable fonts – web fonts – upstream depreciation of non OpenType formats: final stages of the Harfbuzz consolidation decided at the 2006 Text Layout summit https://www.freedesktop.org/wiki/TextLayout/ – appstream & fonts – weak dependencies – and probably more I forget here
It is based on the new fonts-rpm-macros project for automation: https://pagure.io/fonts-rpm-macros/
This project builds on tooling enhancements in redhat-rpm-config and rpm itself, done during the past two years for the Forge and Go sets of packaging macros. It started 2 years ago as a fork of fontpackages, which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default build root, like is done for other domain-specific packaging macro sets.
Major additions: – better documentation (clearer and more complete) – better automation (less packager hassle for better and more complete results)
Major removals: – tools and scripts – fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port ttname to python 3.
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/ showcases the new policy on 62 real-world source packages, generating 139 installation packages. Some of those are badly delayed updates to Fedora packages, others are brand-new packages ready for Fedora inclusion. They include major font packages such as Stix, DejaVu, Droid, IBM Plex.
Existing Fedora packages will continue to build, the old fontpackages macros are grandfathered in fonts-rpm-macros for now. They will be removed in a few years to give packagers time to apply the new guidelines.
Metadata Update from @james: - Issue tagged with: meeting
We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-11-21/fpc.2019-11-21-17.00.txt):
...this will probably be on hold until early next year, as people don't have enough free time to look at it.
Given lack of quorum, going to try voting in the tickets ... +1 from me.
Added some of my 2¢s to the PR, but I might as well vote +1.
My concern is that the policy is enormously long and complicated to comprehend. I don't expect many people going:
And I am seriously afraid, it will be:
Is it acceptable that fonts will only ever be packaged by experts?
We didn't have quorum again, but the four of us did talk about this ticket. You can see the full log here:
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-06/fpc.2020-02-06-17.00.log.html
Basically there is concern that packagers are going to want to look at packaging a font, look at this policy and then run away ... either not packaging it, or just winging it and hoping nobody notices.
My impression was that for simple font packages it should be very simple for a packager to create a font pacakge, just putting files in the right place and filling in an example specfile ... and the macros will do all the complicated bits, but I haven't tried creating a font package and other members thought I might well be wrong. Is my impression correct? If so is it possible to change the policy to highlight this fact to anyone looking to package a font? Eg. an intro. showing how to simple package a font, and then all the complicated bits hidden behind an appendix that says "you shouldn't need to read/understand any of this for simple cases" If my impression isn't true, then is the intention that only a very small number of people will be packaging fonts (basically experienced packagers who deeply understand all of this policy)? If so how would you feel about adding a warning to the policy along the lines of "if you want to package a font, you should really speak to someone in XYZ group/irc-channel to help you out instead of trying to understand this page directly?"
Hi,
I added a short foreword to address your concerns https://pagure.io/fork/nim/packaging-committee/c/6d702f4056142606693e1ba7272d579fa87659ec
That being written.
The difficulty in packaging fonts is not the rpm part. At least, not using the proposed templates. As @james noted, you take the templates, fill in the blanks, and things are done¹. If font upstreams released files in a sane state packaging a font family would be 5 minutes of work, most of this work consisting of spell-checking the package description.
However, to answer @churchyard
Therefore, packaging fonts, does require some level of domain knowledge, to transform the raw material dumps produced by font makers into something useful desktop and server side. The need for this domain knowledge is not occasional, it’s systematic, it can not be handled in an appendix.
On the positive side, the spec deviations software trips on are mostly dead simple and stupid, you do not need expert-level domain knowledge to identify and manage them, just a lot of tedious but easy checking.
That’s why most of the proposed document is a long and tedious (but simple) checklist. Anyone can package fonts in a good state just using this checklist.
And yes, the checklist is long, and it would be awfully convenient if all font project failed at the same part of the list. They do not oblige. They fail because checking things is tedious, not because a specific part of the checklist is hard.
And I would really love for fontconfig to do more of this sanity testing and fixing automatically, making it possible to automate large parts of this checklist, but it does not today and @tagoh can tell you getting to this point is not a couple weeks of work his side.
¹ That FPC feels unable to merge simple “to do X use spec template Y” instructions in guidelines and requires inflicting multiple screenfulls of template rehashing on guideline readers contributes to the length of the document; however that’s not my decision.
@churchyard
I just gonna bundle this font file here and hope nobody notices.
People are already doing this. They will feel entitled to do this as long as the published guidelines provide no value to packagers. To provide value to packagers the guidelines have to be clear and help them produce working packages. Artificialy shortened guidelines are not helpful, they’re a waste of time for everyone involved.
If you want the guidelines to get shorter fonts-side, you need first, to feed more domain knowledge into fontconfig, second to make all first class apps like libreoffice actually use the fontconfig fixes, and third, to win enough market share that font makers notice and do the same fixing by themselves to avoid being let out.
That’s a long-term endeavour.
Thanks for the explanation. +1 in general.
We discussed this at this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-02-13/fpc.2020-02-13-17.00.txt
Metadata Update from @james: - Issue untagged with: meeting - Issue assigned to tibbs - Issue tagged with: writeup
Review request for the support macro package here: https://bugzilla.redhat.com/show_bug.cgi?id=1803281
Metadata Update from @tibbs: - Issue priority set to: In Committee (was: Needs Review)
The macro package is now in the buildroot in F33 and F32. For F31, see https://bodhi.fedoraproject.org/updates/FEDORA-2020-296917559c. Sadly the rebase button doesn't work but I will merge the PR soon. (I don't want to get too far ahead of F31 here, so karma on the update is appreciated.)
Metadata Update from @tibbs: - Issue untagged with: writeup - Issue tagged with: announce
Log in to comment on this ticket.