Should we check for the presence of %install in spec files?

Project Discussion
1

Backstory / Motivation

When I overhauled the spec file for PDF Arranger to the latest packaging guidelines, I accidentally removed the %install makro. It took me over a year to realize this mistake which only became apparent by a rpmlint warning, saysing the man file would not be compressed. Try searching that issue, at least for me it took some time to realize that the missing %install was the issue all along. Otherwise there were no noticeable effects at least for this package no one and nothing complained.

Now I’d like to keep others from going through the same head scratching moments and therefore I’m thinking that a quick check for %install somewhere in the package building process would be a good idea.

Research

A quick search through all the current spec files (Direct download of 27 MiB; I always struggled to find this link when I need it.) reveals eight files which would currently fail this test.

comm -23 <(ls *.spec) <(grep -l “^%install” *.spec)

Let’s split those in two categories:

Meta packages

  • exim-doc.spec
  • fedora-obsolete-packages.spec
  • xorg-x11-drivers.spec

New “BuildSystem: pyproject” packaging

  1. pyshp.spec
  2. python-absl-py.spec
  3. python-asyncpg.spec
  4. python-frozenlist.spec
  5. python-typeguard.spec

Good news: During the writing of this I realize those Python packages are intentionally missing the %install makro, that means no other packages are currently making the same mistake! :+1:

Input wanted

Do you think an automatic check would be useful here? Where and how could it be easily implemented?

How could we deal with those packages that don’t have an explicit call to the %install makro or don’t need it being a metapackage? Could we just add it there without any negative effects to satisfy the check or make it a warning only which can easily be ignored?

2

There are two types of automated checks:

  • the ones that inform[1]
  • the ones that terminate the build

A missing %install section should not terminate the build – there are legitimate usecases for this, as you pointed out.

IMHO, this check only makes sense in the “inform” category e.g. in rpmlint or rpminspect. And it would need to be clever (e.g. it needs to understand declarative build systems and metapackages).

  1. And arguably, nobody not enough folks pay attention to their errors, except when doing package reviews. ↩︎

1 Like
3

Maybe we don’t need a check after all, I went into writing this assuming that the 5 Python packages would have made the same mistake but realized at they end that they are install-less on purpose.

If the next person searching for “rpm man page not compressed” finds this as the solution maybe that is just good enough :thinking: