On 2020-02-13, FPC approved new fonts packaging guidelines: https://pagure.io/packaging-committee/issue/935
They are a major step forward. Existing guidelines were essentially a decade old, had not followed up on rpm improvements, had not followed up on OpenType improvements, had ill-though enhancements bolted on (requiring packagers to write by hand complex font appstream files, deploy them with a lot of boilerplate in their specs, run commands that do not exist anymore in Fedora in their specs, etc). Plus, they were rendered incomprehensible by botched ASCIIDOC conversion.
I’d like to make the new guidelines work in F31, so font packagers have a single packaging target from F31 onwards. At this stage of the F31 cycle, it is highly unlikely that F31 font package changes will be anything but new packages (backported from F33), or bugfix version bumps (backported from F32).
F32 will already ship with the changes applied to important font packages like DejaVu, STIX or Droid. https://src.fedoraproject.org/rpms/google-droid-fonts/c/40ecff95ba6596021818fd2017a30a9000766bcc https://koji.fedoraproject.org/koji/buildinfo?buildID=1469216
The update requires building the same macro package in F31 as in F32 and F33, and pull its SRPM part in the default buildroot via an redhat-rpm-config Requires
Requires
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/bc9a9b302f48c1b8d7cc3935fdc07caa2858b086?branch=f31
The SRPM package weights a few kB and does not pull in any other packages except when building a spec that calls the new font packaging macros. (same no-buildroot-footprint mechanism already used by Go packages for example).
However @pwalter objects to this change and requests FESCO arbitration https://bodhi.fedoraproject.org/updates/FEDORA-2020-296917559c
The new macro set grandfathers anterior fonts packaging macros, so existing specs continue to build as-is. Changes only apply to specs that explicitly call the macros defined in the new packaging guidelines.
Anterior fonts packaging macros are deprecated and will be retired, probably around F34. They have known defects and require packagers to do a lot of manual work in and outside spec files.
Experience shows this manual work not been done except for a handful font packages with @rh maintainers.
As long as old font packages continue build without any single change and work, I have nothing against changing things in F31 even so late in the cycle.
+1 for that. Even for F30.
I can check F30 if FESCO wants.
We are constrained by the state of the redhat-rpm-config common code, I won’t push anything F30-side that requires changing its redhat-rpm-config level
I'm fine with this, since it's opt-in, purely add-on functionality that doesn't break existing packages.
I think Miro wanted to say "something like this would be fine to go into f30 since it doesn't change existing packages", not that you should do it for f30 as well.
Note: I see some packages have incompatible changes since they switched to forge-font-macros, and I reported two bugs for those issues:
But I assume you wouldn't push such changes into stable releases anyway.
Correct.
@decathorpe
Note: I see some packages have incompatible changes since they switched to forge-font-macros, and I reported two bugs for those issues: stix-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=1806271 dejavu-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=1806272 But I assume you wouldn't push such changes into stable releases anyway.
stix-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=1806271 dejavu-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=1806272
Thanks for the reports! I answered in bugzilla, but since you mention it.
stix-fonts is mostly due to a long delayed update to the next upstream major version in Fedora, it’s not directly linked to guideline changes (it’s indirectly linked because the change made such an update possible, when before it was a major PITA and the maintainer, ie me, procrastinated)
dejavu-fonts is due to slightly different file location choices when using the new macros (the old way assumed responsible upstreams, and that proved optimistic). No app should care about the location changes except apps that do not use fontconfig yet. I don’t advise pushing updates of existing packages to previous releases using the new macros (new packages are fine as they don’t have any history with other filepaths).
However, the file path change risk is limited to existing packages, which are used by non-fontconfig apps: a subset of the distribution default font packages, which are a bad bad idea to backport to past releases with or without the macro change, due to their large exposure. Those default font packages are all maintained by experienced packagers that won’t make this kind of mistake (I’ll make an announcement on the lists to remind people once things are settled a bit).
I disagree about not caring on filesystem paths. For example, I maintain some games (I think teeworlds in this case) and they bundle dejavu fonts. I have unbundled by replacing their fonts with symlinka to the fonts coming from Fedora and added dependency on the appropriate fonts package.
@ignatenkobrain and the only reason you had to do that is that your games do not use fontconfig. Fortunately that’s not the general case. Also, this kind of direct filepath use is mostly limited to widely used fonts like DejaVu.
So, for F32+ you get slightly different file paths to symlink. I don’t think one file layout change in 15 years is horrible (especially since the new layout was chosen to make file paths more stable over time, since the previous convention was not resilient to messy upstreams).
* FPC approval is sufficient in this case. (contyk, 16:54:25) * No explicit approval needed for backwards compatible changes Close the ticket. (contyk, 16:59:56)
Metadata Update from @psabata: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.