Hi, On Fri, Jun 21, 2024 at 6:12 PM Sandro <li...@penguinpee.nl> 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
