PackageQuery: Add filter_{latest,earliest}_evr_ignore_arch
#1217
Conversation
| /// @param limit If `limit` > 0, keep `limit` number `evr`s in each group. | ||
| /// If `limit` < 0, keep all **but** `limit` last `evr`s in each group. | ||
| /// @since 5.2 | ||
| void filter_latest_evr_ignore_arch(int limit = 1); |
There was a problem hiding this comment.
I am thinking about naming.
Important information is Group packages by name or Group packages by name and arch. But how it fits with
ignore_arch?
latest and latest_evr - I think latest is always according evr.
There was a problem hiding this comment.
Yeah, I had filter_latest_any_arch in an earlier draft, do you think that's better than filter_latest_ignore_arch? I agree that ignore_arch is not ideal since ignorearch has an established meaning in our project.
I don't like simply filter_latest as much since filter_latest_unresolved_advisories also groups packages by arch; it seems that grouping by name+arch is common for the two existing filter_latest_* functions.
There was a problem hiding this comment.
filter_*_evr_any_arch sounds good to me. Especially when looking to the current state of sources in the package_query.hpp where the docstrings for filter_latest_evr are followed by the filter_latest_evr_any_arch that gives a clear and coherent feeling.
libdnf5/rpm/package_query.cpp
Outdated
| @@ -2471,7 +2505,8 @@ static void filter_first_sorted_by( | |||
| int i; | |||
| for (i = 0; i < samename.size(); ++i) { | |||
| Solvable * considered = pool.id2solvable(samename[i]); | |||
| if (!highest || highest->name != considered->name || highest->arch != considered->arch) { | |||
| if (!highest || highest->name != considered->name || | |||
| (grouping == FilterGrouping::BY_NAME_ARCH && (highest->arch != considered->arch))) { | |||
There was a problem hiding this comment.
Only note with no significant impact on the code. It adds one boolean test which is fast, but for each query this test is performed for each name in sets (Fedora has something like 40 000 package names).
There was a problem hiding this comment.
Hmm, the only alternative I can think of is duplicating the function or at least the for-loop. It should be only one additional AND instruction though?
evan-goode
force-pushed
the
evan-goode/filter-evr-ignore-arch
branch
from
63795c6 to
c6f7523
Compare
|
I may be missing something but how is this breaking ABI? It is adding two new functions to a class that don't overload anything that should be fine no? |
|
Oh 🤦 you're right, I was under the impression that adding any new member would break ABI, but it's only virtual functions and member variables. I can retarget this to |
Resolves rpm-software-management#1111. `filter_latest_evr` and `filter_earliest_evr` group packages by architecture and keep the latest package on each architecture. After `filter_latest_evr`, a PackageQuery might have anaconda-1-1.noarch as well as anaconda-2.2.x86_64. This commit adds `filter_latest_evr_ignore_arch` and `filter_earliest_evr_ignore_arch` which filter for packages with the latest versions regardless of their architecture. Filtering the above anaconda example with `filter_latest_evr_ignore_arch` would result in just {anaconda-2.2.x86_64} since it is the latest version of the package for any arch. This is an ABI-breaking change and thus is targeted at dnf5 5.2.
evan-goode
force-pushed
the
evan-goode/filter-evr-ignore-arch
branch
from
c6f7523 to
9182973
Compare
|
LGTM |
ea3c452
Resolves #1111.
filter_latest_evrandfilter_earliest_evrgroup packages by architecture and keep the latest package on each architecture. Afterfilter_latest_evr, a PackageQuery might have anaconda-1-1.noarch as well as anaconda-2.2.x86_64.This commit adds
filter_latest_evr_ignore_archandfilter_earliest_evr_ignore_archwhich filter for packages with the latest versions regardless of their architecture. Filtering the above anaconda example withfilter_latest_evr_ignore_archwould result in just {anaconda-2.2.x86_64} since it is the latest version of the package for any arch.This is an ABI-breaking change and thus is targeted at dnf5 5.2.