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, -- Nicolas Mailhot _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
