rpm -Uhv --oldpackage loses configs

[Jeffrey Johnson]

> On Jun 7, 2016, at 12:18 PM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
> On Tue, Jun 07, 2016 at 10:48:51 -0400, Jeff Johnson wrote:
> 
>> Yes the metadata header contains those files.
>> 
>> Are the files in the payload?
>> 	rpm2cpio *.rpm | cpio -itv
>> 
>> If the files  are not in the payload, then they will not be installed.
> 
> 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.

The issue with repackaged packages (particularly with %config renaming)
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
to recreate header-only (and possibly header+payload MD5 and signature,
both of which are mostly legacy these days @rpm5.org).

The only metadata information in the payload that is used by rpm is
the file path, which is used to locate the item in the (signed/digested)
header. If the path in the payload is non-existent/modified, then the
file will not be installed.

There’s likely warnings, certainly when -vv is used, but I would have to
look at an actual reproducer to determine what the behavior is with
repackaged package downgraded %config files.

Meanwhile if the files are in the payload (as reported), then there’s likely
a different explanation for why the files are not present after the upgrade/downgrade
aren’t present on the file system.

In order to do install-before-erase, the file disposition has to be computed
for every path so that the erase step does not remove paths that were just
upgraded/downgraded. So what I suspect is happening is that the %config file
is installed and then removed because the file disposition is not set to “skipped”.

So the next diagnostic step is to repeat the operation(s) with -vv and see
what the file disposition is in the remove step, which is displayed after
the file path. Note that on upgrade/downgrade, the “normal” disposition
disposition is not displayed to cut down on some of the sewage.

So, what is seen on the %config file paths if -vv is added?

I predict that the %config files are first installed, but then erased.

73 de Jeff