Merged #1251 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1251#event-3406472496___
Rpm-maint mailing list
Rpm-mai
This pull request **fixes 1 alert** when merging
d3b5712847684c94474c8573f143d619451fcea3 into
869a36c17224ada40614639f1c12345bfc748663 - [view on
LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-49a6843de6d74ec491c6babb53b48b1784a3504f)
**fixed alerts:**
* 1 for Unnece
One more tweak: testing for empty hdrs only actually makes sense for the case
where we do our own dbMatch(), which makes the whole thing a little more
obvious again.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://g
This pull request **fixes 1 alert** when merging
de6b3a0b953e3899e3f395e76d59090227fb8e46 into
869a36c17224ada40614639f1c12345bfc748663 - [view on
LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-e42ccade4ef9b03c99c8b59a08045eb1ea2b1896)
**fixed alerts:**
* 1 for Unnece
Okay, maybe third time's the charm... now with iterators specifically handled
etc, it looks kinda nicer too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1251#issuecomme
All that said, I do agree that allowing an empty match iterator to be passed in
seems like a useful case to support.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1251#is
Eg:
```
>>> bool(ts.dbMatch('packages', 123456789))
True
>>> bool(ts.dbMatch('name', 'xzyd'))
False
>>> bool(ts.dbMatch('name', 'rpm'))
True
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
Eh, this is so broken I doubt anybody can have relied on any particular
behavior.
On RPMDBI_PACKAGES mi is always true whether there is something on it or not,
but eg 'name' matches actually mean something.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
So that empty iterator will pass right through because that iterator is never
false (another quirk in there, deity knows how long), and this new revision
actually reintroduced the specific bug this was supposed to fix.
--
You are receiving this because you are subscribed to this thread.
Reply t
Still not quite sure what the right behaviour is here. Raising the exception
when passing in an non existing header number is all fine. It may also be fine
for a name/label that is not found in the rpmdb. Where things get murky is when
passing in an empty match iterator. I could imagine some cod
Okay @ffesti pointed out that the initial version was buggy too if multiple
entries were being processed, and the logic wasn't that clear anyway. Updated
to just test for no matches-case explicitly, which is much more obvious.
--
You are receiving this because you are subscribed to this thread.
@pmatilai pushed 1 commit.
f7dec8c4a4661cdce945c999c49cba7b2403a2c8 Fix python ts.addErase() not raising
exception on not-found packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1251/files/917c3
The code would only raise an exception if TransactionSetCore.addErase()
returned an error, but the catch is that with many kinds of argument
types we'd silently skip the whole addition because no headers were found.
This looks to be a regression introduced some eleven years ago in
commit 9b20c706a
13 matches
Mail list logo
