[Rpm-maint] [rpm-software-management/rpm] RFE: ability to skip payload while preserving verifiability (Issue #4321)

Panu Matilainen notifications at github.com
Wed Sep 2 10:46:46 UTC 2026


pmatilai created an issue (rpm-software-management/rpm#4321)

Summarizing the original case from https://redhat.atlassian.net/browse/RHEL-186316:

>  let me explain the reasons why the kernel-core package does that way. 
> Kernel-core package is following the directives defined by BLS [1], some of the specifications are:
> 
> - $BOOT could be shared by many OS
> 
> - The kernel files should be located on a file directory owned by the vendor OS, it is supposed that the /boot could be shared with other OS
> 
> - The kernel-core package is also shared between different Red Hat products where the /boot partition behaves in a different way (read only mode or not mounted).
> 
> [...]the vmlinuz-* which is being excluded of the rpm -V verification because it is a %ghost file generated by the copy of the original file to the /boot location. 
> 
> At the end I’m looking for a solution that will allow rpm to verify the /boot/vmlinuz-* files deployed by the kernel-core package.
> 
> [1] https://uapi-group.org/specifications/specs/boot_loader_specification/

In other words, the kernel needs to ship some files to /boot but it can't *package* them there because of the specifications. So it packages them under /lib and copies into /boot from post scriptlets.  The files in /boot are what will be *used* though, so you'd want to be able to verify them, but %ghost files do not support digest verification, for obvious reasons. And %ghost is currently the only way to let rpm know these files will be there at all.

It's a niche case for sure, but a real-world case nevertheless that we currently do not support.

One possible way might be a "%nopayload" %files directive that tells rpm to skip the file from payload but otherwise behave as if its expected to be there, with full verify info etc. That overlaps with %ghost but is quite different ultimately. Whether that's the best way to deal with it I dunno.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/4321
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/4321 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260902/d3598a83/attachment.htm>


More information about the Rpm-maint mailing list