> On May 17, 2018, at 1:38 PM, Francesco <francesco.monto...@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

_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to