rpmlint
rpmlint copied to clipboard
rpm-software-management
Forbid %summary macro
(From http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/12)
using %summary macro in the spec will in most cases go wrong as if you have several sub packages (as you almost always have now that we produce -debug packages too) the %summary macro will get redefined and you'll end up using the summary for the last defined package
Changed 7 years ago by misc
status changed from new to assigned owner changed from misc@… to misc reporter changed from anonymous to pkarlsen@…
we should use something as proposed on http://qa.mandriva.com/show_bug.cgi?id=22427, ie "so something like "forbidden regexp in spec file" ?".
The only problem to me is how to add a configuration system for this. Keeping a big regexp is not a solution, so we need a way to add them one by one, or to place them in a file. Maybe a file with the regexp would be a idea.
This would also help to solve [#7], and maybe other problem.
Another concern i have is the lack of explication for such tests ( as they will likely be quite generic ).
Original comment by: scop
With the new python packaging template 'Summary: %{summary}' has become a very useful pattern. Forbidding this would be quite annoying.
We need to forbid this if there is at least one sub-package. The same for %description.
I shouldn't have been so snarky, sorry.
See the comment from 2015 above: %{summary} is used (with success) in a very common packaging paradigm of python packages. There's above 2000 python packages in Fedora, 99% of them have a binary subpackage different than the main package (because we create a python3-foo binary subpackage from a python-foo src rpm), and some unspecified fraction uses %{summary} to avoid repeating the summary text. Not sure what this fraction is, but used that mechanism when doing a mass rename of binary subpackages for the python3 rename, so I'd guess something on the order of 50%, giving maybe 1000 packages using %{summary} in a way which you want to remove.
Apart from python packages, the same paradigm is used in many many other packages in Fedora with multiple subpackages. And it doesn't result in breakage: a spot check of a few Summary fields shows that they look as expected.
So instead of saying "this should not be used", my suggestion would be to first figure out in which scenario precisely this is broken (since it seems to work just fine in the common case). Second, figure out a nice replacement mechanism that can be used and implement and document it. For example, if there was an macro like %{main_summary} that would give the contents of the Summary of the main package, than this macro could be used to give equivalent functionality, without making the spec files more ugly than now. And finally, once the first two points are done, and people have had time to switch to the new mechanism, start warning the uses which look suspicious.
I haven't tested this, but I think %{SUMMARY} always comes from the main preamble, while %{summary} comes from the last processed version (I might have this backwards, it's hard to remember!).
