There is a bug for fedora review [1] to add some basic support for font packages. It shouldn't be that hard, but time is limited.
One concern is that font specfiles are hard to parse because of the %_font_pkg macro. The problem is that it "hides" the %files directive which is what we use to locate the section (that we have to parse ourselves instead of using rpm's parser is a long story).
Now, anything is possible. But according to the discussion in [2], fpc nowadays seems very firm about that macros should not include any section parts like %files, so %_font_pkg should most likely not have been approved as-is today (?)
So: should the situation be rectified to comply with fpc's view, probably with a new macro not including %files + deprecating %_font_pkg? Not only for fedora-review (which will have to handle %_font_pkg anyway), but for consistency?
--alec
[1] https://fedorahosted.org/FedoraReview/ticket/215 [2] https://fedorahosted.org/fpc/ticket/194
Le Jeu 22 août 2013 12:20, Alec Leamas a écrit :
There is a bug for fedora review [1] to add some basic support for font packages. It shouldn't be that hard, but time is limited.
Thank you for looking at font packages in fedora review.
One concern is that font specfiles are hard to parse because of the %_font_pkg macro. The problem is that it "hides" the %files directive which is what we use to locate the section (that we have to parse ourselves instead of using rpm's parser is a long story).
Now, anything is possible. But according to the discussion in [2], fpc nowadays seems very firm about that macros should not include any section parts like %files, so %_font_pkg should most likely not have been approved as-is today (?)
The objection you reference does not apply to the macros in font packages, the way they are written it is not difficult to complete the files sections (for example it is common to add documentation files)
By construction many font packages have multiple subpackages with specific files sections and lots of repeated boilerplate. Before the macroization spec files were hard to read, errors common and packagers tried to put font files all over the filesystem where fontconfig could not use them. The macros force everyone to respect Fedora guidelines even if they don't understand the font system. They don't get a choice with file placement and permissions and we do not want to give them this choice. (likewise they get little choice over package naming and FPC wishes are enforced by the macros)
Now I won't argue they are perfect, far from that, they were the best compromise that could be found at the time. Please do feel free to propose something better. But better can not be a return to massive boilerplate cut and pasting. Better must keep abstracting all the bits we do not wish font packagers to worry about because choices are locked by fontconfig requirements and FPC decisions.
Regards,
On 2013-08-22 12:49, Nicolas Mailhot wrote:
Le Jeu 22 août 2013 12:20, Alec Leamas a écrit :
There is a bug for fedora review [1] to add some basic support for font packages. It shouldn't be that hard, but time is limited.
Thank you for looking at font packages in fedora review.
Thanks for reply. BTW: are there anything else besides running repo-font-audit which should be done w font packages? More specifically, things to check?
One concern is that font specfiles are hard to parse because of the %_font_pkg macro. The problem is that it "hides" the %files directive which is what we use to locate the section (that we have to parse ourselves instead of using rpm's parser is a long story).
Now, anything is possible. But according to the discussion in [2], fpc nowadays seems very firm about that macros should not include any section parts like %files, so %_font_pkg should most likely not have been approved as-is today (?)
The objection you reference does not apply to the macros in font packages, the way they are written it is not difficult to complete the files sections (for example it is common to add documentation files)
By construction many font packages have multiple subpackages with specific files sections and lots of repeated boilerplate. Before the macroization spec files were hard to read, errors common and packagers tried to put font files all over the filesystem where fontconfig could not use them. The macros force everyone to respect Fedora guidelines even if they don't understand the font system. They don't get a choice with file placement and permissions and we do not want to give them this choice. (likewise they get little choice over package naming and FPC wishes are enforced by the macros)
Now I won't argue they are perfect, far from that, they were the best compromise that could be found at the time. Please do feel free to propose something better. But better can not be a return to massive boilerplate cut and pasting. Better must keep abstracting all the bits we do not wish font packagers to worry about because choices are locked by fontconfig requirements and FPC decisions.
[cut]
The need for abstraction is obvious, and personally I would like to see more of it in fedora specfiles e. g., by using some more of the suse macros.
That said, the core question is if the complete subpackage and scriptlet structure should be hidden. Without diving into this stuff, complete w lua, my first thought is keeping %files, %post and %postun while using specific macros in each section. It's actually the same discussion as in the fpc ticket, isn't it?
The basic argument here is that this exposes the subpackage structure with the different subpackages. I read your post as hiding this within %_font_pkg makes it easier to read. I actually disagree here,. Simple explanation is that when you're used to it, the macro easier. If not, it's harder.
Now, actually changing this is probably beyond what I can achieve. For the moment, I just wanted to discuss the issue to see where it goes...
--alec
Le Jeu 22 août 2013 14:08, Alec Leamas a écrit :
On 2013-08-22 12:49, Nicolas Mailhot wrote:
Le Jeu 22 août 2013 12:20, Alec Leamas a écrit :
There is a bug for fedora review [1] to add some basic support for font packages. It shouldn't be that hard, but time is limited.
Thank you for looking at font packages in fedora review.
Thanks for reply. BTW: are there anything else besides running repo-font-audit which should be done w font packages? More specifically, things to check?
Other checks could be added mid-term, but the priority is to integrate the existing repo-font-audit checks in reviews and autoqa (they are already quite extensive). Someone will probably need to rewrite them in python or something else more easy to integrate later.
That said, the core question is if the complete subpackage and scriptlet structure should be hidden. Without diving into this stuff, complete w lua, my first thought is keeping %files, %post and %postun while using specific macros in each section.
If you do it this way you'll end up replacing one macro call with one macro call per section. At best all this duplication will use the same arguments as the existing macro, at worst each section will require slightly different arguments. This is a recipe for cut and paste mistakes.
Do you realise some font packages have a dozen subpackages? It's already difficult not to make mistakes when ventilating font files between subpackages, the last thing you want is to have to do this repartition multiple times in the same spec.
The ideal technical workflow for font packaging is
1. identify the font families produced by a package, and write the summary/description for each corresponding subpackage (human task)
2. project-specific build process that results in font files in the build-root
3. ventilate each font between subpackages with a %font(subpackagename) fonts-files-list macro (if upstream font metadata sucked less subpackagename could be computed by rpm, with optional human override)
That's all. The macro should take care of the boilerplate since it's always the same (install, files, post, etc)
The reason is that : 1. unlike most software projects font projects do not come with a make-install stage 2. when they do it's wrong 3. but all fonts follow the same packaging rules so nothing after build needs to be project-specific
(it's very similar to special processing done for debug files and doc files)
Now a few years ago rpm could not handle this use-case without the hackish macros we defined, maybe that changed now, if that's the case we can clean up our packaging. But error-prone human cut-and-pasting in spec files is not cleaning up, even if it's easier on tools.
Regards,
-
Alec Leamas -
Nicolas Mailhot