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