[Rpm-maint] Proposal for rpmbuild patch

[Jeff Johnson]

> On May 17, 2018, at 1:38 PM, Francesco <francesco.montorsi at gmail.com> wrote:
> 
> Hi all,
> [I posted a similar proposal under the thread "How to generate GNU make dependency file for a SPEC file automatically?" but I'm reposting here with a better subject]
> 
> Proposal: add a new option to rpmbuild, something like   --generate-md5sum=<output file> that writes the md5sum (or whatever other hash, sha1sum, etc) of all files placed inside the RPM package. Of course the hash would be that associated to the file prior to cpio compression, after all other rpm processing (e.g., stripping of debug info), just before it gets compressed.
> 

You do realize that rpm already computes a digest (usually SHA256, but MD5 can be configured) for all files in a *.rpm package file? That information can be retrieved using --queryformat easily (if make can use digests other than MD5).

Meanwhile -- for general adoption/use in Makefiles -- the glue to generate make dependencies should be as simple as possible. The conversions involved with compression, archive format, and digest algorithm are all obvious, but there really isn't good support to do the operations on a pipe with an archive.

> Rationale: with some simple post-processing such new option would allow to e.g., find in a way transparent to the build system employed by the user (automake, cmake, etc) to understand if a .rpm needs to be regenerated (because some of its packaged files have been changed) or not.

The biggest issue(s) I see are:

1) generating another artifact (other than *.rpm) from rpmbuild would be quite awkward.
rpmbuild (unlike gcc) is 2 layers (shell and %buildroot) from the build tree, and packaging occurs long after the compilation, unlike gcc.

2) rpm has way too many obscure CLI options already. So instead of a CLI option, the approach should be through a configuration macro, using a rule-based value/pattern to generate the output location. A CLI option can always be retrofitted using popt(3) aliases.

But a separate executable, not directly integrated into rpmbuild, might simplify the decompression/archive/digest handling with stdout output, making it easier to automate make dependencies on *.rpm contents, since rpm already has all the necessary implementations.

hth

73 de Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180518/a2bb4621/attachment.html>