core20 and lower snaps, we have been able to build snaps as non root user. This is the case with snapcraft 7.x and lower at least 6.x too IIRC. However, trying to build a
core22 snap with snapcraft 7 as non-root user fails on apt operations, like this:
2022-11-23 20:32:47.615 Executing: ['apt-get', 'update'] 2022-11-23 20:32:48.214 :: Reading package lists... 2022-11-23 20:32:48.223 :: E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) 2022-11-23 20:32:48.223 :: E: Unable to lock directory /var/lib/apt/lists/ 2022-11-23 20:32:48.224 Failed to refresh package list: failed to run apt update. 2022-11-23 20:32:48.228 Traceback (most recent call last): 2022-11-23 20:32:48.228 File "/snap/snapcraft/8567/lib/python3.8/site-packages/craft_parts/packages/deb.py", line 403, in refresh_packages_list 2022-11-23 20:32:48.228 process_run(cmd) 2022-11-23 20:32:48.228 File "/snap/snapcraft/8567/lib/python3.8/site-packages/craft_parts/packages/deb.py", line 746, in process_run 2022-11-23 20:32:48.228 os_utils.process_run(command, logger.debug, **kwargs) 2022-11-23 20:32:48.228 File "/snap/snapcraft/8567/lib/python3.8/site-packages/craft_parts/utils/os_utils.py", line 370, in process_run 2022-11-23 20:32:48.228 raise subprocess.CalledProcessError(ret, command) 2022-11-23 20:32:48.228 subprocess.CalledProcessError: Command '['apt-get', 'update']' returned non-zero exit status 100.
Looking at the code, it seems to be a difference in the way apt update is handled in the “legacy” snapcraft native code vs craft_parts.
Previous code does:
sudo --preserve-env apt-get
Whereas craft_parts code just does:
This is a bit limiting if you are building using
--destructive-mode as a normal user. If you have to sudo the entire snapcraft command, you end up with root owned files in an otherwise non-root working directory [ like somewhere in a user home directly, for instance ].
Is there any reason for the difference in the craft _parts implementation ?
Would a PR that added back default sudo be accepted ?