Re: Q: fedora-review, fonts and %_font_pkg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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.


Nicolas Mailhot

Rpm-list mailing list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux