[Rpm-maint] Proposal for rpmbuild patch

[Francesco]

Hi,
FYI: I released version 1.4 of the Python utility that helps interfacing
rpmbuild to GNU make at:
   https://github.com/f18m/rpm-make-rules-dependency-lister

ChangeLog:

   - changed the way the dependency file is generated: query sha256sums
   directly using rpm program instead of decompressing the rpm with rpm2cpio!
   this speeds up the process and makes it more robust
   - allow searching packaged files in multiple search folders
   - add --strip-dirname option
   - improve docs


HTH,
Francesco


2018-05-18 23:25 GMT+02:00 Francesco <francesco.montorsi at gmail.com>:

> 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 0955c235d9f069b32d22830f661071a33d99425dc5eca69b8da99654c67e
> 0cc7
>
> 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/20180520/da4d32e8/attachment.html>