New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an API for libsolv, libdnf, et al to use to check if rpmdb has changed and trivially get path to rpmdb #388
Comments
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
May 23, 2019
…nged Add rpmdbCookie() public function and matching python bindings. The returned value is an opaque string which changes any time the rpmdb is changed (eg packages added or removed, rebuild changes things etc). A key point is that this is entirely database backend agnostic. The actual implementation here is an SHA1 hash of RPMDBI_NAME keys, but this is an implementation detail that can be changed anytime and callers must not rely on. The only thing that matters is whether the string equals an earlier cookie value or not. A cryptographic hash seems like an overkill, but then it saves us the headaches of coming up with something that reflects order changes etc. Closes: rpm-software-management#388
A simple cookie API implemented in PR #712 , comments welcome. |
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
May 23, 2019
…nged Add rpmdbCookie() public function and matching python bindings. The returned value is an opaque string which changes any time the rpmdb is changed (eg packages added or removed, rebuild changes things etc). A key point is that this is entirely database backend agnostic. The actual implementation here is an SHA1 hash of RPMDBI_NAME keys and the corresponding package offsets, but this is an implementation detail that can be changed anytime and callers must not rely on. The only thing that matters is whether the string equals an earlier cookie value or not. A cryptographic hash seems like an overkill, but then it saves us the headaches of coming up with something that reflects order changes etc. Closes: rpm-software-management#388
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
May 27, 2019
…nged Add rpmdbCookie() public function and matching python bindings. The returned value is an opaque string which changes any time the rpmdb is changed (eg packages added or removed, rebuild changes things etc). A key point is that this is entirely database backend agnostic. The actual implementation here is an SHA1 hash of RPMDBI_NAME keys and the corresponding package offsets, but this is an implementation detail that can be changed anytime and callers must not rely on. The only thing that matters is whether the string equals an earlier cookie value or not. A cryptographic hash seems like an overkill, but then it saves us the headaches of coming up with something that reflects order changes etc. Closes: rpm-software-management#388
ffesti
pushed a commit
that referenced
this issue
May 27, 2019
…nged Add rpmdbCookie() public function and matching python bindings. The returned value is an opaque string which changes any time the rpmdb is changed (eg packages added or removed, rebuild changes things etc). A key point is that this is entirely database backend agnostic. The actual implementation here is an SHA1 hash of RPMDBI_NAME keys and the corresponding package offsets, but this is an implementation detail that can be changed anytime and callers must not rely on. The only thing that matters is whether the string equals an earlier cookie value or not. A cryptographic hash seems like an overkill, but then it saves us the headaches of coming up with something that reflects order changes etc. Closes: #388
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Quoted from @pmatilai in rpm-software-management/libdnf#362 (comment):
Also quoted from @pmatilai in rpm-software-management/libdnf#362 (comment):
I'm currently beginning experiments with non-BDB rpmdb, but these assumptions made about how the rpmdb exists causes problems, as I need to patch them to "know" the alternative paths used by the different backends.
It'd be nice if there was a nice backend-agnostic set of APIs to solve these problems in libsolv, libdnf, and dnf so that this stops being a problem and even as more backends and changes to existing ones occur, everything won't break.
(Also filing this so it doesn't get forgotten again...)
The text was updated successfully, but these errors were encountered: