`charmcraft pack` retains no longer existing files from previous packs
Metadata
Current evaluation
Repacking reuses the part's build container, so files deleted from the working tree linger in the resulting charm until `charmcraft clean <part>`. Maintainers confirmed it still reproduces; root cause tracked upstream in craft-parts#851.
Suggested action: keep open
Reason: The issue is Triaged/Bug and maintainer lengau explicitly re-confirmed it on 2024-09-20 ("Confirmed this is still an issue. I've made an upstream bug report: canonical/craft-parts/issues/851"), which is still open with a reproducer and test but no fix; facundobatista also confirmed it "still there in latest release". A workaround exists (`charmcraft clean <part-name>`), but that does not fix the underlying behaviour in craft_parts/sources/local_source.py, whose update() only copies updated files/dirs and never deletes files removed from the local source.
Evaluated by: mr-cal-bot
Impact:
55
Quick Win:
18
Complexity:
60
Confidence:
85
Actionability:
80
Issue body
When I repack a charm, the resulting charm has a file that no longer exists in the working directory:
```
> $ ls src/prometheus_alert_rules
total 16K
drwxrwxr-x 2 tux tux 4.0K Mar 10 15:00 .
drwxrwxr-x 5 tux tux 4.0K Mar 10 15:00 ..
-rw-rw-r-- 1 tux tux 323 Mar 10 15:00 always_firing_absent.rule
-rw-rw-r-- 1 tux tux 301 Mar 10 15:00 always_firing_numeric.rule
> $ charmcraft pack
Charms packed:
avalanche-k8s_ubuntu-20.04-amd64.charm
> $ unzip -l avalanche-k8s_ubuntu-20.04-amd64.charm | grep always_firing
306 2021-12-01 19:21 src/prometheus_alert_rules/always_firing.rule
323 2022-03-10 20:00 src/prometheus_alert_rules/always_firing_absent.rule
301 2022-03-10 20:00 src/prometheus_alert_rules/always_firing_numeric.rule
```
Note how `src/prometheus_alert_rules/always_firing.rule` doesn't exist in the workdir, but is present in the archive.
This issue went away after `clean`:
```
> $ charmcraft clean
Cleaned project 'avalanche-k8s'.
> $ charmcraft pack
Charms packed:
avalanche-k8s_ubuntu-20.04-amd64.charm
> $ unzip -l avalanche-k8s_ubuntu-20.04-amd64.charm | grep always_firing
323 2022-03-10 20:00 src/prometheus_alert_rules/always_firing_absent.rule
301 2022-03-10 20:00 src/prometheus_alert_rules/always_firing_numeric.rule
```
## Environment
- Charmcraft 1.4.0
- lxd 4.23
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
55
Quick Win:
18
Complexity:
60
Confidence:
85
Actionability:
80
|
keep open | Repacking reuses the part's build container, so files deleted from the working tree linger in the resulting charm until `charmcraft clean <part>`. Maintainers confirmed it still reproduces; root cause tracked upstream in craft-parts#851. | |
| qwen/qwen3.6-35b-a3b |
Impact:
60
Quick Win:
25
Complexity:
40
Confidence:
85
Actionability:
70
|
keep open | charmcraft pack retains deleted files from previous builds; upstream craft-parts#851 filed, still open as of Oct 2024 | |
| qwen/qwen3.8-27b |
Impact:
45
Quick Win:
25
Staleness:
55
Complexity:
45
Confidence:
82
Support Request:
5
|
keep open | charmcraft pack includes files deleted from the working directory in the charm archive; clean fixes it. Triaged as a known bug, re-confirmed present in Oct 2024, upstream craft-parts bug filed, per-part clean workaround documented. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
65
Complexity:
45
Confidence:
85
Support Request:
10
|
keep open | charmcraft pack includes deleted files from previous builds. Triaged bug, confirmed by maintainers, with an upstream craft-parts issue and a workaround. Last activity ~10 months ago. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
50
Complexity:
40
Confidence:
95
Support Request:
5
|
keep open | charmcraft pack includes deleted files from previous builds. Triaged bug, confirmed active by maintainers, with an upstream fix tracked in craft-parts. Workaround available. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
65
Complexity:
45
Confidence:
85
Support Request:
10
|
keep open | charmcraft pack retains deleted files from previous builds. Triaged bug confirmed still present in latest versions, with an upstream issue linked and a workaround documented. |
Update history
No update history recorded yet.
Related work
-
Related To:
charmcraft#746
(confidence 90%)
Same stale-file bug reported separately; closed as a duplicate of charmcraft#710, so #710 is the canonical tracking issue.
-
Blocked By:
canonical/craft-parts#851
(confidence 88%)
Maintainer-filed upstream report for the same defect ('Removed files from local sources remain in the part'); still open, triaged, reproducer/test added but fix not implemented.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #746 `charmcraft pack` for existing environment does not remove files that have been deleted | charmcraft | closed | Closed as a duplicate of charmcraft#710 by maintainer facundobatativa (facundobatista) on 2022-04-13. #710 remains open, with the root cause tracked upstream in craft-parts#851. | |
| #552 `charmcraft pack` runs indefinitely when using parts | charmcraft | closed | The hang was caused by duplicated local-source ignore patterns in Charmcraft 1.2.1 and fixed in 1.3.0 via canonical/craft-parts#120 (commit 280e1592). | |
| #2273 charmcraft.yaml deleted while packing (working tree not clean) | charmcraft | open | Packing a Charmcraft 3.4.3 reproducer deletes tracked charmcraft.yaml before a dump part, making git describe --dirty tag release builds incompatible; untriaged and apparently unresolved | |
| #1160 `charmcraft pack` does not recognize updated `charmcraft.yaml` file | charmcraft | open | Tracked upstream: charmcraft pack ignores build-snaps channel changes in charmcraft.yaml unless clean is run. Root cause is craft-parts#496 (build-snaps missing from properties_of_interest), still unfixed; charmcraft only needs a craft-parts bump once patched. | |
| #907 `charmcraft pack` does not handle updating a file's execution permissions without a `charmcraft clean` | charmcraft | open | charmcraft pack keeps stale file permissions in the build container unless `charmcraft clean` is run; root cause is craft-parts' outdated check only comparing mtime. Reproduced upstream, workaround `touch` documented, still open. | |
| #501 charmcraft pack fails trying to include a non-existing charm/src/.tox/ | charmcraft | closed | The missing-file packing failure was fixed upstream in craft-parts; maintainer lengau closed charmcraft#501 on 2024-02-22 as resolved. | |
| #1791 Charmcraft 3 including previously-built charms in new charm builds | charmcraft | closed | Fixed in PR #1793 (commit affc209b): subsequent charmcraft pack runs no longer include previously built .charm artifacts in the new charm. |