Backport countme bucket calculation fix #1613
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The buckets aren't really an array that's indexed in the code, they're just sequential numbers for the URL flag. Also clarify why we're using "this window" instead of "the current position of the sliding window" in the comments. Backport from dnf4: rpm-software-management/libdnf@cc95edd
Actually use the system's installation time (if known) as the reference point, instead of the first-ever countme event recorded for the given repo. This is what the dnf5.conf(5) man page always said about the countme option, the code just never lived up to that. This makes bucket calculation more accurate: 1. System upgrades will no longer reset the bucket to 1 (this used to be the case due to a new persistdir being created whenever $releasever changed). 2. Systems that only reach out to the repos after an initial time period after being installed will no longer appear younger than they really are. 3. Prebuilt OS images that happen to include countme cookies created at build time will no longer cause all the instances spawned from those images (physical machines, VMs or containers) to appear older than they really are. Use the machine-id(5) file's mtime to infer the installation time. This file is semantically tied to the system's lifetime since it's typically populated at installation time or during the first boot by an installer tool or init system, respectively, and remains unchanged. The fact that it's a well-defined file with clear semantics ensures that OS images won't accidentally include a prepopulated version of this file with a timestamp corresponding to the image build, unlike our own cookie files (see point 3 above). In some cases, such as in OCI containers without an init system running, the machine-id file may be missing or empty, even though the system is still used long-term. To cover those, keep the original, relative epoch as a fallback method. System upgrades aren't really a thing for such systems so the above point 1 doesn't apply here. Some containers, such as those created by toolbox(1), may also choose to bind-mount the host's machine-id file, thus falling into the same bucket as their host. Conveniently, that's what we want, since the purpose of such containers is to blend with the host as much as possible. Backport from dnf4: rpm-software-management/libdnf@cc95edd
Make it a bit more explanatory, format the age buckets as a table and reflect the changes from the last update. Backport from dnf4: rpm-software-management/dnf@a8c77bb
Conan-Kudo
approved these changes
Aug 8, 2024
Merged
via the queue into
rpm-software-management:main
with commit Aug 8, 2024
8c64096
16 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backporting rpm-software-management/libdnf#1662 and rpm-software-management/dnf#2093
Tests: rpm-software-management/ci-dnf-stack#1501
Since the dnf5 code was identical to dnf4 code the patch is also almost exactly the same (only the names differ like:
get_system_epochvsgetSystemEpoch).