On Fri, Jun 21, 2024 at 8:20 PM Sandro <lists@xxxxxxxxxxxxx> wrote:
On 21-06-2024 16:11, Parag Nemade wrote:
> 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/
Thanks for the information. I still think this should have been
announced beforehand. An impact check should have brought that to light
before pushing the update to rawhide and then PRs could have been
provided for building in a side tag.
Is this change going to propagate to stable branches as well? If not,
the change in path only applies to Fedora >= 41 and the symlink creation
in the spec file needs to be guarded by %if / %else.
I never thought updating SPEC to follow new font packaging guidelines would break as the package name remained the same and I did not expect other packages to use a hard path of this font package.
I will check if there are any more packages using the old Liberation font installation path and will fix it.
I already updated my PR to have changed for Fedora > 41.
> 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
Thanks. I already fixed it myself and pushed a PR just before yours.
> I am not aware of any packaging change for unifont package so can't speak
> for that here.
As I wrote above, nothing has changed in unifont. The last update to
that package was about a year ago. I suspect the change is due to
updated fonts-rpm-macros. But I haven't looked into it to make sure.
Moreover, my initial analysis wasn't entirely correct. I was going by
what was specified in the specfile. The BR was listed as unifont-fonts
before things broke.
On my F39 system:
$ repoquery -q --cache --provides /usr/share/fonts/unifont/unifont.ttf
font(unifont)
font(unifontupper)
metainfo()
metainfo(unifont.metainfo.xml)
unifont-ttf-fonts = 15.0.01-3.fc39
I will be changing the BR to `font(unifont)` and do the same for
Liberation Sans. That should safeguard against future renames.
-- Sandro
--
_______________________________________________
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
-- _______________________________________________ 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
