Skip to content
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

Backport countme bucket calculation fix #1613

Merged
merged 3 commits into from
Aug 8, 2024

Commits on Aug 6, 2024

  1. Fix up some comments in addCountmeFlag()

    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
    kontura committed Aug 6, 2024
    Configuration menu
    Copy the full SHA
    32a104b View commit details
    Browse the repository at this point in the history
  2. Fix countme bucket calculation

    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
    kontura committed Aug 6, 2024
    Configuration menu
    Copy the full SHA
    fa99d56 View commit details
    Browse the repository at this point in the history
  3. Update the man page entry for the countme option

    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
    kontura committed Aug 6, 2024
    Configuration menu
    Copy the full SHA
    39c1932 View commit details
    Browse the repository at this point in the history