rpm -Uhv --oldpackage loses configs
Jeffrey Johnson
n3npq at me.com
Tue Jun 7 19:55:50 CEST 2016
> On Jun 7, 2016, at 1:49 PM, Tomasz Pala <gotar at polanet.pl> wrote:
>
> Note: I'm not referring to %config issue reported, this is only by-the-way question.
>
> On Tue, Jun 07, 2016 at 13:16:45 -0400, Jeffrey Johnson wrote:
>
>>> A propos - would it be possible for rpm to support "--verify --package"
>>> exactly for this purpose, i.e. verifying metadata/manifest against cpio
>>> archive contents (including file checksums) without installing package.rpm?
>>
>> All rpm operations are supported for any rpm package.
>
> But --verify checks against filesystem. I'm looking for a way to check
> against cpio inside…
>
OK.
>> is different however. The payload when the repackaged payload is constructed
>> is ???best effort??? in the sense that if a file does not exist on its metadata path, then
>> the file cannot be included in the package. Similarly, if a file is modified
>> from the original content, there is no attempt to recalculate file digests, which
>> would also trigger a recalculation of the header SHA1 and (harder) resigning
> [...]
>
> ...just for such cases as you described. In other words: I want to check
> if repackaged.rpm contains changed files. Let's name it: integrity test
> (manifest vs cpio).
>
> Currently I'm able to do it by installing such package in newly created
> (empty) root and verifying against files put inside, but there should be
> more elegant/effective way. Considering the --install checks digests
> (thus --nomd5/--nodigest was required to install repackaged.rpms with
> modified contents), it should be enough to skip appropriate code path,
> the one that actually commits filesystem changes.
>
If you diff rpm -qplv and rpm2cpio … | cpio-itv spewage, you will verify
that all the cpio headers are identical to what is in metadata.
Those 2 outputs were identical at one point in time, but the sewage display
conventions for rpm/cpio might have changed since implemented.
73 de Jeff
More information about the pld-devel-en
mailing list