DevHeads.net

Fonts packaging policy rewrite proposal

Hi,

A fonts packaging policy rewrite proposal has been pushed to FPC today:
<a href="https://pagure.io/packaging-committee/pull-request/934" title="https://pagure.io/packaging-committee/pull-request/934">https://pagure.io/packaging-committee/pull-request/934</a>

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
<a href="https://www.freedesktop.org/wiki/TextLayout/" title="https://www.freedesktop.org/wiki/TextLayout/">https://www.freedesktop.org/wiki/TextLayout/</a>
– appstream & fonts
– weak dependencies
– and probably more I forget here

It is based on the new fonts-rpm-macros project for automation:

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.

<a href="https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/" title="https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/">https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/</a>

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.

Regards,

Comments

Re: Fonts packaging policy rewrite proposal

By Akira TAGOH at 11/12/2019 - 04:06

On Tue, Nov 12, 2019 at 5:01 PM Nicolas Mailhot
<nicolas. ... at laposte dot net> wrote:
That would probably be better covering all of the default fonts at
least so we don't see any regressions by this major updates on the
policy.

The missing packages would be:

- abattis-cantarell-fonts
- adobe-source-code-pro-fonts
- gnu-free-fonts
- google-noto-fonts
- google-noto-cjk-fonts
- google-noto-emoji-fonts
- jomolhari-fonts
- lohit-assamese-fonts
- lohit-bengali-fonts
- lohit-devanagari-fonts
- lohit-gujarati-fonts
- lohit-kannada-fonts
- lohit-odia-fonts
- lohit-tamil-fonts
- lohit-telugu-fonts
- khmeros-fonts
- paktype-naskh-basic-fonts
- sil-abyssinica-fonts
- sil-nuosu-fonts
- sil-padauk-fonts
- smc-meera-fonts
- thai-scalable-fonts

I don't have a time to work on it this week but may have some next week perhaps.

Re: Fonts packaging policy rewrite proposal

By Vitaly Zaitsev ... at 11/12/2019 - 05:38

Le 2019-11-12 10:06, Akira TAGOH a écrit :
Hi Akira

Well I think I did my part here:) the copr covers all the font packages
I maintain, and adds support for all the SIL and GFS fonts we had not
packaged yet, and some more (like Plex).

I don't have the time and energy to repackage everything by myself, and
anyway that would not demonstrate that the new macros and guidelines are
usable by anyone but myself (so, really, not so useful).

I think the copr demonstrates that the technical implementation works,
on a huge and diverse pool of real-world font projects.

I spent a *huge* amount of time making those specs conform to the
proposed packaging templates, dotting i's, slashing t's, going back to
the drawing board any time the templates didn’t work out in practice,
automating things that wasted my time as a packager.

You can diff the guideline examples, the templates, and the implemented
specs you'll see they are all identical, and can all serve as packaging
examples

Regards,