Re: Breaking changes to fonts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Jun 21, 2024 at 6:12 PM Sandro <lists@xxxxxxxxxxxxx> wrote:
Hi,

Looking into flare-engine failing to build from source, I encountered
two issues with font packages:

1. Path change in liberation-sans-fonts
2. Name change of subpkg for unifont

The first appeared trivial. The path to the fonts was changed from
`/usr/share/fonts/liberation-sans` to
`/usr/share/fonts/liberation-sans-fonts` in
liberation-sans-fonts-1:2.1.5-11.fc41.noarch. That broke the symlink
flare-engine creates. Easy fix. Yet still a surprise.

For the second change I haven't been able to figure out with certainty
what package is responsible. Looks like it might be changes to
fonts-rpm-macros.

The issue is `/usr/share/fonts/unifont/unifont.ttf` is no longer
provided by unifont-fonts, but by unifont-ttf-fonts. However, package
unifont hasn't seen any update in a year. So, the cause must be outside
that package.

Either way, it's a breaking change that should have been announced here.
Preferably, this should have been dealt with by proper Obsoletes /
Provides if possible. But maybe I missed something.

For flare and flare-engine, there's a check in the spec file checking
for broken symlinks. Without that this change might have gone unnoticed,
leaving the packages in a broken state.

Not all font packages still follow the new fonts packaging guidelines in Fedora. And when those guidelines got approved some years back, it was known that many font packages would break the path. The font installation path is determined by the font family name as per Fonts packaging policy.

The liberation-fonts and liberation-narrow-fonts were long overdue to convert its SPEC. The reason why a simple SPEC conversion of liberation-fonts broke was because the metapackage liberation-fonts-all generation did not have a way to auto add obsoletes/provides on main package rpm names that include Epoch: value. This has been fixed now in https://src.fedoraproject.org/rpms/fonts-rpm-macros/c/381fa2dd4653094832e36ceb7a34ed8c245be5c8?branch=rawhide
That was realized later after I built the package in rawhide. The latest liberation-fonts-all metapackage now also provides the older liberation-fonts package.

If packages in Fedora are using hardcoded installation paths of liberation fonts then they need to be fixed. I request all the package owners whose packages are using hard coded path to liberation fonts, please update your spec to use a new font installed path.
e.g. Path /usr/share/fonts/liberation-sans/ changed to /usr/share/fonts/liberation-sans-fonts/
Path /usr/share/fonts/liberation-serif/ changed to /usr/share/fonts/liberation-serif-fonts/
Patch /usr/share/fonts/liberation-mono/ changed to /usr/share/fonts/liberation-mono-fonts/

If anyone needs help with their packages do reply to me and I will be happy to help you. For flare-engine package here is PR https://src.fedoraproject.org/rpms/flare-engine/pull-request/9

I am not aware of any packaging change for unifont package so can't speak for that here.

Regards,
Parag
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux