Since there is no obvious way to add comments on the rpm.org wiki here is one on
« Rule based subpackages »
They are IMHO quite unnecessary and do not put the packager in control of what file ends up in what package (when you can have tens or hundreds of files that may hit a rule you absolutely do not want them to be put in a single automated subpackage automatically. And this is an actual use case for fonts and tex, for example).
A much better solution would be to enhance rpm macro support so it's possible to easily define %doc-like verbs for use in %files
For example:
%files blue
%fonts blue*ttf
%fonts Blue*otf
%fontconfig blue*.conf
%icon blue*.png blue*.svg
% files red
%fonts red*ttf
%icon red*.png red*.svg
That leaves the packager in control of where the files end up and would simplify spec files a lot. Anything else will make it quite difficult to handle obsoletes, provides, writing useful subpackage summaries, etc. Also, it IMHO fits the rpm model quite well and is "natural" for packagers. Trying to generate the whole subpackage instead of just the parts that can be sanely automated is not a good idea.
However, it requires a solid way to define %foo verbs that can inject processing in %install, %post, %postun, maybe Provides/Requires, maybe %build/BuildRequires, etc
Right now if you try even the simple trick of pre-generating %post rpm will complain of multiple %posts for the same subpackage.
The file arguments to %foo would be paths to files present in the buildroot after the manually-defined %build (since %build is often package-specific).
