← Back to issue list

`charmcraft pack` does not handle updating a file's execution permissions without a `charmcraft clean`

View original Github issue

Metadata

Project
charmcraft
Number
#907
Type
issue
State
open
Author
ca-scribner
Labels
Created
Updated
Closed

Current evaluation

charmcraft pack ignores local file permission changes (e.g., chmod +x on src/charm.py) until a full charmcraft clean, causing confusing lint errors. Maintainer reproduced and filed upstream craft-parts#311; still unfixed.

Suggested action: keep open

Reason: Maintainer facundobatista reproduced the bug, gave a touch-based workaround, and filed upstream canonical/craft-parts#311, which is still open. I verified craft-parts' local_source.check_if_outdated still compares only st_mtime (no st_mode check), so the bug is unfixed and this issue is blocked on that upstream fix rather than stale or irrelevant.

Impact: 55 Quick Win: 24.75 Staleness: 65 Complexity: 55 Confidence: 85 Support Request: 10

Issue body

# What happened `charmcraft pack` will error out if you try to pack a charm with a `src/charm.py` that does not have execution permission on the file. If you fix the permissions and then `pack` again, it will respond with the same message. You need to `clean` the charmcraft env before packing for this to work as expected. # What did you expect If I change the permissions on a file locally, I expect `charmcraft pack` to either reproduce those changes in my container or error specifically telling me it cannot do that. Instead, the current implementation quietly ignores some differences between my local files and container, leading users to continue debugging things they've already fixed just because it is not transparent whether the fix made it into the container. # Reproduction ```bash git clone https://github.com/canonical/template-operator cd template-operator chmod a-x src/charm.py charmcraft pack # Fails with an error saying the charm file is not executable chmod a+x src/charm.py charmcraft pack # Still fails with an error saying the charm file is not executable charmcraft clean charmcraft pack # Works ``` # Additional comments A mitigation is to use `charmcraft clean` liberally whenever you're not sure if something will propagate to the container, but that is a poor user experience. Cold-start for charmcraft is slow (minutes vs 10's of seconds) and very disruptive to an iterative workflow

Evaluation history

Date Model Scores Action Summary
qwen/qwen3.8-27b
Impact: 55
Quick Win: 24.75
Staleness: 65
Complexity: 55
Confidence: 85
Support Request: 10
keep open charmcraft pack ignores local file permission changes (e.g., chmod +x on src/charm.py) until a full charmcraft clean, causing confusing lint errors. Maintainer reproduced and filed upstream craft-parts#311; still unfixed.
qwen/qwen3.6-35b-a3b
Staleness: 80
Complexity: 65
Confidence: 70
Support Request: 10
keep open charmcraft pack ignores file permission changes without a clean, causing silent build failures. Acknowledged and tracked upstream, but unlabelled and inactive for over a year.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 55
Confidence: 80
Support Request: 10
keep open charmcraft pack fails to detect file permission changes without a clean. Maintainer reproduced it, linked to upstream craft-parts, and provided a workaround. Issue remains open but inactive for over 10 months.
qwen3.6-35b-a3b-mtp-q6
Staleness: 88
Complexity: 55
Confidence: 70
Support Request: 10
keep open Acknowledged bug where charmcraft pack fails to detect file permission changes without clean. Maintainer reproduced it, linked to upstream craft-parts issue, and provided a workaround. Awaiting upstream resolution.
qwen3.6-35b-a3b-mtp-q6
Staleness: 60
Complexity: 35
Confidence: 85
Support Request: 5
keep open charmcraft pack ignores local file permission changes, requiring charmcraft clean to apply them. Craft Parts fails to track permission updates. Tracked internally as CRAFT-3250. Workaround: run touch on modified files. Currently awaiting upstream fix.

Update history

No update history recorded yet.

Related work

  • Blocked By: canonical/craft-parts#311 (confidence 95%)

    Explicitly referenced by the maintainer as the upstream issue where the permission-change detection fix belongs; still open and unlabelled.

  • Related To: canonical/charmcraft#736 (confidence 45%)

    Commenter noted a similar symptom (files not detected as updated after moving the LXC container between machines), suggesting the same mtime-based diff limitation; that issue was closed as unreproducible.

Related issues

Issue Project State Summary Similarity
#1931 Successfully pack charm with incorrect charm.py file permission charmcraft open charmcraft pack succeeds even when src/charm.py lacks the execute bit, producing a charm that fails at deploy with 'Permission denied'. Requested a warning/error or auto-fix at pack time. No maintainer activity; an entrypoint linter now exists but only runs via charmcraft analyze, not pack.
80%
#710 `charmcraft pack` retains no longer existing files from previous packs charmcraft 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.
76%
#1160 `charmcraft pack` does not recognize updated `charmcraft.yaml` file charmcraft open charmcraft pack ignores updated build-snaps channel in charmcraft.yaml without a clean; tracked as a craft-parts bug (canonical/craft-parts#496, still open) awaiting a dependency patch release to pull into charmcraft.
75%
#497 charmcraft Pack is not Working charmcraft closed Resolved via user environment fix. The permission error stemmed from running charmcraft as root with root-owned files. Switching to a regular user, adding them to the lxd group, and correcting ownership allowed pack to succeed. No code changes required.
74%
#501 charmcraft pack fails trying to include a non-existing charm/src/.tox/ charmcraft closed charmcraft pack failed when copying non-existent build directories or files. Users worked around it with charmcraft clean. The issue was closed as fixed upstream in the underlying parts lifecycle code.
73%
#1530 Changing charmcraft.yaml doesn't update the resulting charm's metadata.yaml charmcraft open Bug: editing charmcraft.yaml then re-running `charmcraft pack` does not update the resulting charm's metadata.yaml. Filed by a maintainer (lengau); last comment (2024-09-09) says it's unclear if still reproducible. Related open craft-application#821 describes the same 'Already packed' skip behavior.
72%
#2402 Odd error when packing charmcraft closed A typo in charmcraft caused a chown command to fail with a permission string. The author identified it should be chmod. The issue was closed, confirming the bug was fixed in charmcraft to resolve the packing error.
71%
#1930 `charmcraft pack -o` fails: `FileNotFoundError` charmcraft closed A FileNotFoundError with charmcraft pack -o was abandoned and closed without resolution. No fix was implemented, and a recent comment confirms the bug persists.
70%
#552 `charmcraft pack` runs indefinitely when using parts charmcraft closed The charmcraft pack hang was caused by a duplicate ignore patterns bug. This was fixed in Charmcraft 1.3.0. The author confirmed they would upgrade and close the issue pending recurrence.
70%
#746 `charmcraft pack` for existing environment does not remove files that have been deleted charmcraft closed Closed as a duplicate of issue #710. The charmcraft pack command was reported to retain deleted files in the charm archive across builds. Resolution and tracking are handled in the referenced duplicate issue.
70%