Add rpm db consistency plugin

[fcrozat]

Ensure RPM database is always consistent (all dependencies are fulfilled) and revert to previous snapshot if not.

[sysrich]

Awesome change, LGTM!

[laenion]

Yes, LGTM, too!

Who's taking it? @schubi2, are you taking it?

[laenion]

It turned out this check is too invasive because it

1. Requires network access to update the package database
2. Checks not only for database consistency, but also for dependencies. Including keys that haven't been added to the database. Both cases can occur in "regular" operation (when the admin confirms it) and are way more than the plugin name suggests: Just checking whether the RPM database is readable.

Maybe something like rpm --verifydb would make more sense?

[fcrozat]

I'm not 100% sure rpm --verifydb would catch all the issues found by zypper.

zypper is called with --no-refresh, so it shouldn't do any network access.

[thkukuk]

I'm not 100% sure rpm --verifydb would catch all the issues found by zypper.

It will not, but not all issues zypper finds are a reason to do a rollback. E.g. unresolved dependencies of RPMs are sometimes wanted by the admin.

zypper is called with --no-refresh, so it shouldn't do any network access.

That's not correct, --no-refresh will not refresh the cache, but it does not forbid zypper to fetch missing data via network. And that's the problem: data is missing and no network, zypper fails.

[fcrozat]

I'm not 100% sure rpm --verifydb would catch all the issues found by zypper.

It will not, but not all issues zypper finds are a reason to do a rollback. E.g. unresolved dependencies of RPMs are sometimes wanted by the admin.

If an admin choose to shoot themself in the foot, fine, but he/she should disable this healthcheck then.

zypper is called with --no-refresh, so it shouldn't do any network access.

That's not correct, --no-refresh will not refresh the cache, but it does not forbid zypper to fetch missing data via network. And that's the problem: data is missing and no network, zypper fails.

The point of this plugin was to ensure RPM db was always consistent (not just readable). Switching to rpm --verifydb won't allow that. I'll see if I can improve the script to only run zypper if metadata are present on the system.

[laenion]

It will not, but not all issues zypper finds are a reason to do a rollback. E.g. unresolved dependencies of RPMs are sometimes wanted by the admin.

If an admin choose to shoot themself in the foot, fine, but he/she should disable this healthcheck then.

I'm using a setup where I had to "shoot myself in the foot": A third-party package was packaged for Red Had distributions only, using a different package name as a dependency. When just ignoring that dependency everything is working perfectly fine though.

I'd still like to have a check for a broken RPM database though, because at least on test machines I got into that situation a few times already, especially at the time when the database backend was migrated...