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