https://bugzilla.redhat.com/show_bug.cgi?id=1806272
--- Comment #27 from Hans de Goede hdegoede@redhat.com --- (In reply to Nicolas Mailhot from comment #26)
(In reply to Hans de Goede from comment #24)
Thank you for adding the compat packages.
I must be honest though, this is not entirely what I was expecting. I was expecting the compat symlinks to be part of the main dejavu-sans-fonts, dejavu-serif-fonts, etc. packages. That way they will automatically just be there, without packages depending on say dejavu-sans-fonts needing to adjust their Requires.
https://src.fedoraproject.org/rpms/dejavu-fonts/blob/f32/f/dejavu-fonts. spec#_151
Ah I looked over the Supplements line, cool. Thank you this will give us a whole cycle to deal with the fallout of this, much appreciated.
The idea here is to make things more future proof, so that we can deal with any future font-file-path changes with just a rebuild.
It will be a little more future-proof, but not as much as you think. Fonts are evolving outside the one style = one file model. Mostly, due to the influence of web fonts, because CSS uses a stacking model, identical to the one in fontconfig. Styles can now be spread over multiple files (that is already true for the Math extension of DejaVu Serif) or, on the contrary, be merged into a single file (variable fonts).
Ok I understand, if:
BuildRequires: font(dejavusans) fontconfig
+
fc-match -f "%{file}" "sans"
Ever results in the second command suggesting a font which is not suitable as a default font for "legacy" ttf users, then I guess we will need to come up with a different way of handling this at that point in time. Since we do not know what the font situation will exactly look like then, I don't think that speculating on this now is all that useful. So for now I'll just go with the 'ln -s $(fc-match -f "%{file}" "sans") $RPM_BUILD_ROOT%{_datadir}/%{name}/font.ttf' approach.