Presumably the desired rpm API is some Boolean valued function that returns the 
value "changed" with minimal hassle.

What isn't clear is what changed means: time stamp since ... ? package count 
has changed since ... ? digest on files composing an rpmdb?

There is certainly existing prior art in yum detecting rpmdb changes (though 
it's unclear whether yum knows about anything but BDB). There are also 
nitpicking details (like w yum) about what "changed" means that need to be 
defined. E.g. yum complains if an rpmdb is changed by a manual rpm command.

Since the predominant paradigm of depsolvers like DNF/libsolv is to strip all 
rpmdb info initially and then run a install/upgrade/erase transaction (with 
implicit rpmdb changes under exclusive write lock), it's unclear (to me 
anyways) how an API would be used.

Detecting paths to multiple back ends based on macros isn't that difficult. 
Harder is the problem of, say, having multiple co-existing back ends: which 
back end should be used to compute "changed"?
Shoukd a back end switch, or a --rebuilddb, constitute a "change"?

There is the further problem of keeping time stamps across --rebuilddb to 
prevent backup software based on time stamps from needlessly backing up rpmdb's

All solvable problems, just not sure whether an API is all that useful.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to