At some point the location used for dejavu-sans-fonts changed. This would break Hedgewars, but no one had reported it yet.

Ok, I'm confused... I don't even see a font packaged in the F31 build. Also, I noticed your recent builds. Do I still need to do anything?

It only changed in f32 and rawhide, so probably not many people were likely to notice.

I'm hoping to fix it myself. This bug is mostly to let others know what is going on.
I wasn't sure how far back the font directory change for dejavu-sans-fonts went.
I'm hoping to have something that works for both working soon.
I also noted the README file changed and README.md should get added. I'll do that at the same time.

Bruno, here is what I did for the widelands package (which uses a lot of fonts):

%global fonts font(amiri) font(dejavusans) font(dejavusansmono) font(dejavuserif) font(widelands) font(lklug) font(wenquanyimicrohei)

# For the %%build part generating the symlinks
BuildRequires: fontconfig %{fonts}

pushd $RPM_BUILD_ROOT

ln -s $(fc-match -f "%{file}" "amiri") \
  usr/share/%{name}/i18n/fonts/amiri-fonts/amiri-regular.ttf
ln -s $(fc-match -f "%{file}" "amiri:bold") \
  usr/share/%{name}/i18n/fonts/amiri-fonts/amiri-bold.ttf
ln -s $(fc-match -f "%{file}" "amiri:italic") \
  usr/share/%{name}/i18n/fonts/amiri-fonts/amiri-slanted.ttf
ln -s $(fc-match -f "%{file}" "amiri:bold:italic") \
  usr/share/%{name}/i18n/fonts/amiri-fonts/amiri-boldslanted.ttf

ln -s $(fc-match -f "%{file}" "sans") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSans.ttf
ln -s $(fc-match -f "%{file}" "sans:bold") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSans-Bold.ttf
ln -s $(fc-match -f "%{file}" "sans:italic") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSans-Oblique.ttf
ln -s $(fc-match -f "%{file}" "sans:bold:italic") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSans-BoldOblique.ttf
ln -s $(fc-match -f "%{file}" "serif") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSerif.ttf
ln -s $(fc-match -f "%{file}" "serif:bold") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSerif-Bold.ttf
ln -s $(fc-match -f "%{file}" "serif:italic") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSerif-Italic.ttf
ln -s $(fc-match -f "%{file}" "serif:bold:italic") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSerif-BoldItalic.ttf
ln -s $(fc-match -f "%{file}" "monospace") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSansMono.ttf
ln -s $(fc-match -f "%{file}" "monospace:bold") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSansMono-Bold.ttf
ln -s $(fc-match -f "%{file}" "monospace:italic") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSansMono-Oblique.ttf
ln -s $(fc-match -f "%{file}" "monospace:bold:italic") \
  usr/share/%{name}/i18n/fonts/dejavu-fonts/DejaVuSansMono-BoldOblique.ttf

...

popd

This will also future proof things against future filename changes of the dejavu fonts.

I vaguely remember (and there is a note in the spec file) that there is an issue with using sym links and physfs. I'm going to generate a list of font directories that are installed by dependencies. Ideally hedgewars would look for fonts at run time rather than build tine, but that isn't something I want to figure out and either maintain or upstream.
Whatever build time solution is used, is going to break if a required font changes directory due to its package changing.
I hope that this is something that is only done before mass rebuilds. Even so, nobody reported a bug for this during f32's development. I only noticed because the package failed rebuilding after the qt5 update. And then it took a bit to figure out what the real problem was, because I hadn't looked at it in a long time.

I do thank you for the font example. I might need that in the future for the normal case where symlinks don't cause problems. I hadn't seen the fontconfig way of noting font dependencies before. Plus I had been looking at fcmatch, but I was struggling to figure out how to get it to provide the just the filename, and you have that in your example.

Even if they wanted to do the font stuff at build time, it would have been nice if they had used fc commands in the cmake files instead of looking for a filename match in each directory for each font (by filename, not properties).

FEDORA-2020-2a48c023ec has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2a48c023ec

FEDORA-2020-9dc9de34ba has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9dc9de34ba

Hedgewars should be installable in the next rawhide compose.
I believe that hedgewars was broken in f32, but I don't have an f32 instance to double check. I expect the game to error out when being played. The tutorial on throwing grenades seemed to be one place that happened. A fixed version has been pushed to testing.
I pushed a fixed version as an enhancement for f31 even though it isn't currently broken. That will make rebuilding there easier if a font directory changes there. Though it does look like the dejavu fonts upgrade to 2.37 alreay happened there, but the directory didn't change.

Ok, so a few more things related to the above discussion, in case anyone reading along here needs the info:

1. The font directory changing is indeed only a change for F32+ and after some discussion with the maintainers about this breaking many games, a compat package was added which adds compat symlinks with the old file-paths. See bug 1806272 for details. The compat packages Supplement the main dejavu-fonts packages for which they add the compat symlinks so they will be installed automatically.

2. I have a list of games against which I plan to file bugs for the dejavu file-path changes + some generic instructions / advice on using fc-match to fix this in a future proof way, but I have not gotten around to this yet. Likewise I also have a list of games which I maintain myself where I need to fix this myself.

3. I'm not sure what the fix for hedgewars now is. But a warning about using a symlink to a directory: things get tricky if you want to switch to using symlinks to individual font files, which better matches with fc-match usage. I found this out the hard way with widelands, so the widelands spec now has this to handle the switch from F31 symlink to font dirs to F32 symlinks to individual files:

"""
pushd $RPM_BUILD_ROOT
# Replace fonts with system fonts. We used to have symlinks directly from
# i18n/fonts/<widelands-name> to the /usr/share/fonts/<system-font-name> dir
# but with recent font packaging changes this no longer works because e.g.
# Widelands expects all DejaVu fonts in a single dir, where as now there are
# separate /usr/share/fonts dirs for the sans, sans-mono and serif versions.
#
# Replacing the symlinks at the dir level with keeping the
# i18n/fonts/<widelands-name> directory and then putting symlinks to the
# invidual font-files inside that directory does not work, because on upgrade
# that would mean replacing a symlink with a dir which breaks horribly.
# So for those cases where we used to have a symlink, we create a new dir
# under i18n/fonts with a different name, with symlinks to the individual
# files in that dir; and then point the symlink to this new dir, to avoid
# the replace a symlink with a dir problem.
rm -r usr/share/%{name}/i18n/fonts/amiri
mkdir usr/share/%{name}/i18n/fonts/amiri-fonts
ln -s amiri-fonts usr/share/%{name}/i18n/fonts/amiri
"""

So we make a new dir (with a different name) under the games data dir in which to store the symlinks to the individual font files and replace the original bundled fonts dir with a symlink to that dir. This way on F31 upgrade we replace the symlink to /use/share/fonts/amiri with a symlink to the new /usr/share/widelands/i18n/fonts/amiri-fonts, so that we replace a symlink with a symlink on upgrade which rpm/dnf can handle.

Note, if you search the web there is a lua %pre-trans scriptlet which allows replacing symlinks with dirs at the rpm level, but dnf will do a transaction check / dry-run before running the %pre-trans scriptlets and that will fail, so that does not help.

FEDORA-2020-2a48c023ec has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2a48c023ec`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2a48c023ec

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-9dc9de34ba has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9dc9de34ba`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9dc9de34ba

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

What I did to fix hedgewars (because the physfs security package blocked symlinks) is pass cmake a list of all of the directories one level below %{_datadir}/fonts and it looks there for files with matching names. That was a minimal change to the build process. You still need to know which font packages are actually needed and include those in buildrequires.

FEDORA-2020-2a48c023ec has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-9dc9de34ba has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Thanks guys!