Repo info: add unique NEVRAs count#2731
Conversation
jrohel
left a comment
jrohel
left a comment
There was a problem hiding this comment.
The code is simple and looks OK functionally. However, I spot an ABI break at first glance. Two approaches come to mind:
-
We agree on a point when we will introduce breaking changes. But generally speaking, we should minimize breaking the library's ABI.
-
We create a new interface, for example
IRepoInfo2_1, which will inherit fromIRepoInfoand contain the newly added method. This would introduce interface versioning. Usage of the passed interface object (e.g., in libdnf5-cli/output/repo_info.cpp) would then require checking which class it inherits from to determine which methods are available.
This way, we would remain backward compatible. Applications compiled with an older version of the library (using the original IRepoInfo) would continue to work with the new library. (Of course, in this case, the new library wouldn't report the number of unique NEVRs, because it wouldn't receive them from the old application using the old interface).
| virtual uint64_t get_size() const = 0; | ||
| virtual uint64_t get_pkgs() const = 0; | ||
| virtual uint64_t get_available_pkgs() const = 0; | ||
| virtual uint64_t get_unique_nevras() const = 0; |
There was a problem hiding this comment.
Adding a virtual method to a public interface class causes a public ABI break.
2 participants
Port rpm-software-management/dnf#2324 to dnf5.
Tests: rpm-software-management/ci-dnf-stack#1880