Fedora Account System
Red Hat Associate
Red Hat Customer
It appears that the urw-base35-fonts package SPEC file uses "Provides" and "Obsoletes" against the urw-fonts package. Might I suggest that it does likewise for the "ghostscript-fonts" package? Sadly, while the urw-base35-fonts package does obsolete urw-fonts it does not actually "provide" it. In particular, urw-fonts provided a font path of: /usr/share/fonts/default/Type1 And ghostscript-fonts provided a font path of: /usr/share/fonts/default/ghostscript It was easy to extrapolate the /usr/share/fonts/default commonality to mean something for finding the .afm files. The urw-base35-fonts package provides /usr/share/fonts/urw-base35 which does not "provide" /usr/share/fonts/default/Type1 or /usr/share/fonts/default/ghostscript or even /usr/share/fonts/default. So, while the functionality of the urw-fonts (and ghostscript-fonts) package is provided, software that is built to look for those fonts in /usr/share/fonts/default will be unable to find them.
Hello Lee, (In reply to Lee Howard from comment #0) > It appears that the urw-base35-fonts package SPEC file uses "Provides" and > "Obsoletes" against the urw-fonts package. Might I suggest that it does > likewise for the "ghostscript-fonts" package? thank you for you suggestion. Unfortunately, I won't be adding that into urw-base35-fonts specfile, because of these reasons: 1) It should have been 'urw-fonts' that should have added Obsolete against 'ghostscript-fonts' a very long time ago. For some reason, nobody ever did it. I'd like to keep the urw-base35-fonts specfile as clean as possible. 2) I will be killing the 'urw-fonts' package soon for F27 and Rawhide, where the 'urw-base35-fonts' already live. 3) Currently, there's only one package that depends on 'ghostscript-fonts', and that is 'hylafax+'. I have already managed to do a scratch-build of it against the new 'urw-base35-fonts'. At the moment, there's ongoing discussion on how to deal with the 'ghostscript-fonts' removal for the future. Based on these facts, and on what's going on around it at the moment, it does not seem to me that adding the Obsoletes on 'ghostscript-fonts' is worth the time & troubles. I hope you understand. > Sadly, while the urw-base35-fonts package does obsolete urw-fonts it does > not actually "provide" it. Actually, they do provide it. The 'urw-fonts' is a package of Postscript Core Font Set [Level 2], same as what 'urw-base35-fonts' provide. https://en.wikipedia.org/wiki/PostScript_fonts#Core_Font_Set We're not looking for 1:1 replacement here. Instead, we're providing the same number of fonts that are supposed to be used mainly with Ghostscript, and that comply with the the specification of Level 2 Core Font Set (see the Wikipedia link). > In particular, urw-fonts provided a font path of: > > /usr/share/fonts/default/Type1 Yes, and the new fonts package provides this path instead: >> /usr/share/fonts/urw-base35 That path is with accordance to Fedora Packaging Guidelines (FPG) for fonts. > And ghostscript-fonts provided a font path of: > > /usr/share/fonts/default/ghostscript 'ghostscript-fonts' are dead, lets keep them away from this. :) > It was easy to extrapolate the /usr/share/fonts/default commonality to mean > something for finding the .afm files. The metric files (*.afm) still exists for the fonts in the new 'urw-base35-fonts' package. If some of your packages have problems finding the new path, then the package needs to be updated to properly locate the new fonts -- same as it was done for Ghostscript in BZ #1500105. > The urw-base35-fonts package provides /usr/share/fonts/urw-base35 which does > not "provide" /usr/share/fonts/default/Type1 or > /usr/share/fonts/default/ghostscript or even /usr/share/fonts/default. As I mentioned above, the Provides: is meant to notify other dependant packages that this is a replacement of the old fonts, and that these new fonts can be used instead of the old ones. In other words it says "here's the new replacement of Core Font Set Level 2", not the same exact paths. Providing the same path would make sense to me for some critical (binary/script) applications, for example in a way of a symlink, but not for the fonts. Because if the application/script is written correctly, it should either be able to find the new fonts automatically, or use the fontconfig to find an adequate replacement for the time being. Of course, I could have provided the symlinks to the old font path, but that wouldn't "force" other applications using these old fonts to update for the new path, thus blocking the progress. And even if I would use these symlinks only for (lets say) 2 releases of Fedora, then it would just most likely postpone the problem, because the maintainers/developers wouldn't be "forced" to update the font path. > So, while the functionality of the urw-fonts (and ghostscript-fonts) package > is provided, software that is built to look for those fonts in > /usr/share/fonts/default will be unable to find them. Yes, and I said - we're not looking to be backward compatible for forever. If this happens, that software needs to be updated - either just by changing the path in the specfile, or by notifying upstream to fix their configuration. (Which has already happened for ImageMagick for example.)