Packaging .c files in a non-devel package


I’m currently working on a Fedora package for make-it-quick (<a href="" title=""></a>), a make-only build system with basic auto-configuration.

rpmlint complains about shipping .c files in a non -devel package. The package does contains several small .c files that are used for autoconfiguration.

One option would be to rename the package as “make-it-quick-devel”, but that seems a bit redundant given that the whole point of the package is to be a development tool.

Another option would be to rename the files to use some custom extension for configuration sources. But that seems more like obfuscation, and I don’t like doing that just to silence rpmlint.

Can you suggest a good approach?

Christophe de Dinechin


Re: Packaging .c files in a non-devel package

By Dan =?utf-8?B?x... at 03/14/2019 - 05:18

Hi Christophe,

since the .c files appear to be fundamental for the functionality of
make-it-quick, I'd rather silence this one specific check via an
rpmlintrc file instead of renaming them or converting this into a -devel

Renaming them is probably a lot more work and calling it -devel will
confuse end users. Both are imho not worth it just for the sake of
silencing a single rpmlint warning.



Christophe de Dinechin < ... at redhat dot com> writes:

Re: Packaging .c files in a non-devel package

By Fabio Valentini at 03/14/2019 - 08:08

On Thu, Mar 14, 2019, 10:19 Dan Čermák <>


I think there is (or at least, there used to be) a section in the packaging
guidelines which explicitly mentions that including both .c and .h files in
non-devel packages is fine (and indeed, expected) for compilers and build
tools which need those files at runtime.


Re: Packaging .c files in a non-devel package

By Felix Schwarz at 03/14/2019 - 18:57

Am 14.03.19 um 13:08 schrieb Fabio Valentini:
<a href="" title=""></a> :


Re: Packaging .c files in a non-devel package

By Christophe de D... at 03/15/2019 - 07:22

Thank you for pointing that out. I’ll follow the rpmlintrc approach to silence the warning, then.