On Fri, Jun 21, 2024 at 8:20 PM Sandro <li...@penguinpee.nl> wrote:
> On 21-06-2024 16:11, Parag Nemade wrote: > > 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/ > > 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@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 >
-- _______________________________________________ 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
