I took over the maintenance of urw-fonts to update them to the latest version (ghostscript and other packages needs them). However, there are several problems in versioning of it, and I would like to discuss future steps for the package.
The current problems:
* our urw-fonts are kind of old (~2 years), and ghostscript is unable to build without latest version correctly
(unless I patch it, and it would still cause ghostscript crashes for some instances AFAIK)
* according to git log the urw-fonts in Fedora should be based on version 1.10, but the source code archive indicates version 1.07 pre-release
(1.06 in fact, if we check the source code)
* the NVR of urw-fonts does not correlate to this at all - urw-fonts-2.4-22.fc24.noarch
* we obtain the source archive from Artifex (aka upstream responsible for ghostscript), nowadays they are no longer using the X.Y.Z versioning system. Instead, they have created a separate git repository for it, and are doing "snapshot based" releases... Their latest release is: urw-base35-20160926.zip
* I asked them if they could go back to X.Y.Z versioning system, here's what Chris Liddell replied:
"If you check the versions in the font files, you'll see why I switched to the release dates.
For several releases they never changed from 1.10, and with the latest release, they're back to 1.00.
Since this is how URW++ release them to us, there's not a huge amount we can do."
* and as you can see above, they also changed the name from 'urw-fonts' to 'urw-base35' because of this
As you can see, the versioning of urw-fonts is total mess right now, and I would like to bring back some order to it, but I don't want it to backfire on me because of how URW++ tends to version their fonts... Here's my proposed solution to this:
- create a new package for urw-fonts which would obsolete the current urw-fonts
- choose a similar name to the new package - 'urw-base35-fonts' or similar
2) or map the X.Y.Z versioning to YYYYMMDD from upstream - IOW - X == Year, Y == Month, Z == Day (based on the snapshot date in the name of the source archive)
3) or set the Version to some constant (35 for example) and just use the snapshot to distinguish between older and newer releases.
I am affraid that I would pick option 1) it could pose problems in the future again, because there's not guarantee that URW++ will follow sane versioning. So, personally, I would choose 2) or 3).
There's also one more option, and that is to base the package on upstream's git repository and the snapshot scheme, because we would be using snapshot string in the package name anyway. And it would also solve one more issue that upstream is not shipping license files in the archive. (I have already contacted to correct this.)
What are you thoughts, guys? Anyone has a better idea how to solve this mess? Or which option would you recommend?
Thank you in advance for all your ideas.
RED HAT | TRIED. TESTED. TRUSTED.
David Kaspar [Dee'Kej]
Associate Software Engineer
Brno, Czech Republic
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat.