145 package BuildRequire python3-sphinx_rtd_theme, now fail to build from source. Nominating as a prioritized bug.

Hi,

I'm very sorry for this.

The old version was providing:
config(fontawesome-fonts) = 4.7.0-8.fc33
font(fontawesome)
fontawesome-fonts = 4.7.0-8.fc33

While the new one provides:
config(fontawesome-fonts) = 5.13.1-1.fc33
font(fontawesome5brands)
font(fontawesome5brandsregular)
font(fontawesome5free)
font(fontawesome5freeregular)
font(fontawesome5freesolid)
fontawesome-fonts = 5.13.1-1.fc33
metainfo()
metainfo(fontawesome.metainfo.xml)

Speaking on IRC, my understanding is that there are 3 possible ways to fix this:
1. create a link from /usr/share/fonts/fontawesome/Font Awesome 5 Free-Regular-400.otf to /usr/share/fonts/fontawesome/FontAwesome.otf so that the new package provides the expected font. Being a major release, some glyphs have been dropped/renamed, but the majority should still work
2. epoch the package, move it back to 4 and create fontawesome5-fonts for FA5
3. leave the package as is and create fontawesome4-fonts for FA4

What would be the best approach to this?

Right. Apparently upstream has made changes a lot between 4 and 5.

https://fontawesome.com/how-to-use/on-the-desktop/setup/upgrading-from-version-4

(In reply to Fabio Alessandro Locati from comment #2)
> 1. create a link from /usr/share/fonts/fontawesome/Font Awesome 5
> Free-Regular-400.otf to /usr/share/fonts/fontawesome/FontAwesome.otf so that
> the new package provides the expected font. Being a major release, some
> glyphs have been dropped/renamed, but the majority should still work

If they are exactly same, that should works. but is it really same?

> 2. epoch the package, move it back to 4 and create fontawesome5-fonts for FA5

As it is stated at https://github.com/FortAwesome/Font-Awesome/tree/4f4cb7c2f55d14d24f10390ebfeab0d25af612f3, 4 is EOL'd. the main package name should be provided for 5 or later.

> 3. leave the package as is and create fontawesome4-fonts for FA4

So this way looks good to me and better correcting something in the dependant packages for 5 in the future.

> 
> What would be the best approach to this?

yeah it happens when upstream change font family names or any of inside font file metadata info.

1) I think other packages can be moved to use "font(fontawesome5free)" instead of "font(fontawesome)" now
OR
2) add additional virtual Provides: font(fontawesome) in rawhide

Hi,

At the desktop and server level, you need to add fontconfig aliasing, so the old name is aliased to the new one (and the new one should be something without version, to avoid breakage at the next release).

If there is no symbol overlap between font files, or if the overlaps do not matter, all font files should be aliased to a single unified font family (you can check in the droid package how such stacking in a signle font family can be achieved)

If there *is* symbol overlap and users need to be able to disambiguate between overlapping symbol versions, you need to create as many (synthetic) font families as necessary to insure symbols are reacheable.

This sorting work will give you the number of subpackages to create, since our guidelines mandate separating disctinct logical font families indistinct subpackages.

Unfortunately, font provides will be broken because fontconfig does not permit consulting new fontconfig rules at package build time. I reported that to fontconfig maintainers ages ago, back when they were using bugzilla, and reported it again a few months ago
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/225


As long as you do all that things will work transparently in apps and font lists, for any app that accesses fonts via fontconfig (ie, all that matter nowadays).


There is the special case of apps that access fonts via file paths. This is broken for OpenType files, since OpenType allows the spreading of a font family over multiple files, and all the major font projects I know relayouted their files at one time or another for technical reasons.


Apps that access font families via file paths (mostly old games and CSS-using webapps) are required to rebuild their font configuration every time one of the font project they use relayouts. This can be done via manual config changes or by calling fontconfig at build time to ask it what the current file paths are. The gaming SIG did the second recently because some major font projects had relayouted between F31 and F32.


Above all you should not take the cop out of publishing several slightly different versions of the same font family. That seems to work at first but quickly degenerates into problems when two apps use different versions of the same thing with slightly different behaviour.

Multipackaging (be it multi version, or multi format) is prohibited by our guidelines and requires FPC approval (quite heavy handed process but that was the only way to prevent packagers from taking the easy initial way out, and dealing with years of problems afterwards).

Version fontawesome-fonts-5.13.1-2.fc33 is going in the next comp.
Hopefully is solves the problem, since it provides:

config(fontawesome-fonts) = 5.13.1-1.fc33
font(fontawesome)
font(fontawesome5brands)
font(fontawesome5brandsregular)
font(fontawesome5free)
font(fontawesome5freeregular)
font(fontawesome5freesolid)
fontawesome-fonts = 5.13.1-1.fc33


Thanks a lot Nicolas for all the help and support you provided :-)

FEDORA-2020-14eda4c7a7 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-14eda4c7a7

Thanks for the awesomely quick fix! However I'm not sure if providing font(fontawesome) will be good enough :/

For example, python-sphinx_rtd_theme currently has:
	
ln -s %{_datadir}/fonts/fontawesome/fontawesome-webfont.eot .
ln -s %{_datadir}/fonts/fontawesome/fontawesome-webfont.svg .
ln -s %{_datadir}/fonts/fontawesome/fontawesome-webfont.ttf .
ln -s %{_datadir}/fonts/fontawesome/fontawesome-webfont.woff .
ln -s %{_datadir}/fonts/fontawesome/fontawesome-webfont.woff2 .

And the files are not packaged, correct? I can only assume other packages do similar things.

/usr/share/fonts/fontawesome/fontawesome-webfont.ttf was provided by that package, while the others were provided by fontawesome-fonts-web.

The ttf file got dropped since upstream affirms that otf is to be preferred over the ttf. We were shipping both, which creates QA problems.

The other files are still in the same package (fontawesome-fonts-web) but got renamed to:
/usr/share/fonts/fontawesome/fa-regular-400.eot
/usr/share/fonts/fontawesome/fa-regular-400.svg
/usr/share/fonts/fontawesome/fa-regular-400.woff
/usr/share/fonts/fontawesome/fa-regular-400.woff2

we could provide symlinks for those, but not sure it would be the best way

The effects of the update have been far greater than my expectation.
I've epoched and rollback the package that is now back at 4.7.0-8.
The update should be in the next comp.
I will work on a more sustainable update proposal/update path following the system-wide change process.
Thanks a lot for your suggestions on how this change can happen in a way that is sustainable for dependent packages.

FEDORA-2020-c5957bcd91 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c5957bcd91

Thanks for the rollback, Fabio!

 Problem: package fontawesome-fonts-web-5.13.1-1.fc33.noarch requires fontawesome-fonts = 5.13.1-1.fc33, but none of the providers can be installed
  - cannot install both fontawesome-fonts-5.13.1-1.fc33.noarch and fontawesome-fonts-1:4.7.0-8.fc33.noarch

%package web
...
Requires:	%{fontname}-fonts = %{version}-%{release}

This need an epoch. I'll correct it.

FEDORA-2020-6575d6210a has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6575d6210a