Thanks to visit codestin.com
Credit goes to github.com

Skip to content

apt: make clean idempotent by checking for cached files#86362

Closed
Jkhall81 wants to merge 1 commit intoansible:develfrom
Jkhall81:feature/84880-apt-clean-idempotency
Closed

apt: make clean idempotent by checking for cached files#86362
Jkhall81 wants to merge 1 commit intoansible:develfrom
Jkhall81:feature/84880-apt-clean-idempotency

Conversation

@Jkhall81
Copy link
Contributor

@Jkhall81 Jkhall81 commented Dec 21, 2025

SUMMARY
This PR makes the apt module's clean parameter idempotent by ensuring it only reports a changed state when files are actually removed from the cache.

Previously, apt: clean: yes always returend changed: true. This change implements a filesystem check on /var/cache/apt/archives/ and its partial/ subdirectory to detect the presence of .deb files or incomplete downloads before executing the clean command.

Fixes #84880
Signed-off-by: Jason Hall [email protected]

ISSUE TYPE
Feature Pull Request

COMPONENT NAME
lib/ansible/modules/apt.py
test/integration/targets/apt/tasks/clean.yml
changelogs/fragments/84880-apt-clean-idempotency.yml

@Jkhall81 Jkhall81 force-pushed the feature/84880-apt-clean-idempotency branch from ad46bde to c4236a4 Compare December 21, 2025 16:48
@ansibot ansibot added needs_triage Needs a first human triage before being processed. module This issue/PR relates to a module. has_issue labels Dec 21, 2025
Copy link
Member

@Akasurde Akasurde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, will wait for others to comment.

@flowerysong
Copy link
Contributor

-1. The new code still runs the command even when it claims there's no change, so it's neither acting on information returned from the command to report whether a change actually occurred, nor avoiding the possibility that any change occurred by skipping the command.

I think the previous behaviour is the best that can be achieved: it is already idempotent (running it twice has the same result as running it once), the return value just accurately reflects that the command it runs does not provide a way to tell whether a change was made.

@Jkhall81
Copy link
Contributor Author

I appreciate the feedback, but I respectfully disagree that the previous behavior is the best that can be achieved.

The concern regarding 'acting on information' applies equally, if not more so, to the previous behavior. The previous logic is guaranteed to report a false-positive changed state 100% of the time the cache is already clean. This implementation prioritizes resolving this persistent inaccuracy, which is a documented pain point for users.

Also, I find the suggestion to revert to the original behavior contradictory: if the current patch is considered inadequate because the command still runs, the original behavior is even more so, as it executes the same command without any state-checking at all.

@flowerysong
Copy link
Contributor

With your proposed change, it is possible for the module to change something and report that it made no changes. This is much worse than claiming it made changes when it didn't.

@ansibot ansibot added the stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested. label Dec 30, 2025
if f.endswith('.deb'):
changed = True
break

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this could be problematic, as it assumes there is no change to the cache contents between this check and when apt-get clean is actually run. This is a bit of a race condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same logic that applies to almost every check in Ansible. Unless I'm missing something. Modules like file and copy all check the state first and then act on it.

apt-get clean doesn't give us a way to check its status while it's running. Is there a specific risk or error this causes that I'm missing? If not, this is the most practical way to fix the current bug. If this even is a bug. There seems to be disagreement about that.

@bcoca bcoca removed the needs_triage Needs a first human triage before being processed. label Jan 15, 2026
@Jkhall81 Jkhall81 closed this by deleting the head repository Jan 24, 2026
@ansible ansible locked and limited conversation to collaborators Feb 21, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

has_issue module This issue/PR relates to a module. stale_ci This PR has been tested by CI more than one week ago. Close and re-open this PR to get it retested.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make apt clean mark as change only if something was actually cleaned

6 participants