[Rpm-maint] Proposal for rpmbuild patch

Francesco francesco.montorsi at gmail.com
Fri May 18 21:25:24 UTC 2018


Hi Jeff,


2018-05-18 18:54 GMT+02:00 Jeff Johnson <n3npq at me.com>:
>
> 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).
>

No, I really did not know that. I explored --queryformat and found out on
my Centos7 system that indeed the command
     rpm -q --qf '[%{filenames} %{FILEMD5S}\n]' coreutils | grep date
provides:
/usr/bin/date
0955c235d9f069b32d22830f661071a33d99425dc5eca69b8da99654c67e0cc7

that really looks exactly what I needed!
Actually as you say that's not a md5 checksum (as the tag name FILEMD5S
would suggest) but rather a sha256 checksum, but for my purpose there's no
difference.



> 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.
>
>
Sure. I wrote a Python utility just for speed but perhaps a small C utility
would be better (to reduce dependencies) to do the glue operations.


> 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.
>

Yeah, at this point the idea of doing an rpmbuild patch is not really
useful anymore. I was not aware that rpm was able to do all what is needed
to achieve what I proposed (smarter rpm regeneration).



>
> hth
>
>
Yes, that helped, thanks!

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


More information about the Rpm-maint mailing list