I make some moderately complex rpm and deb packages (~25K files). As part of our testing process I want to compare build packages against a baseline manifest and report/fail on various kinds of differences. For example:

• a file in the baseline is missing in the package
• a file in the package is not in the baseline
• a file changed modes or owners
• a symlink now points to a different place
• a file changed size by more than some % delta.

Since many of our packages are large, we obviously don't want to unpack the reference baseline and the built package and compare the file system trees. Comparing the stream of items as we unpack is preferable, so we never have to materialize a manifest.

The use cases are:

• Create a manifest from a live filesystem
• Create a manifest a .deb, .rpm, .msi, ...
• Compare a manifest against the stream from a freshly built package.

The comparison tools should be more of a library than a stand-alone tool, as every org will have different ideas about what they care about.

Questions

How do we handle the notion of containers within containers.

For example, .deb files are an ar style wrapper over gzip'ed tarballs. The manifest must support that notion. In a similar way, an RPM has a large header section containing relevant items like post-install scripts. The headers are almost their own container, except the

What is built in to a reference implementation of a compare tool?

• Suppress compares against particular path globs.
• Do we just dump all diffs to a known file format and let people write tests that depend on that input data?
• What compressions are must have's for MVP
• Do we build a stream differ for RPM headers. For reference, a JSON dump of the datadog agent RPM headers is over 5MiB uncompressed. I would rather not have to materialize that if I don't have to.

MVP implementation

• DEB: Pretty easy. We have the ar reader, unzip and untar for the data.tar.gz is well known
• RPM: I put together rpm and cpio readers in https://github.com/aiuto/rules_pkg/tree/rpm/tools/rpm.
• MSI: obvious work to do.