> On Jun 7, 2016, at 12:18 PM, Tomasz Pala <[email protected]> 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 _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
