Installing optional workloads when using 6.0-preview Linux snap packages

[ar0311]

Hi,

Any info on if installing optional workloads is possible when using the Linux snap delivered SDK?

Cheers

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ar0311]

The Linux snap lives in a read-only filesystem FYI which seems to be the problem.

[wli3]

@leecow do we have plan for snap?

[soma-kurisu]

can you sketch out the moving parts involved and give a rough vision of what an enterprise grade solution must provide to finally fix that problem?

my current setup in use:

$ dotnet --list-sdks
8.0.100 [/snap/dotnet-sdk/228/sdk]

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 23.10"
NAME="Ubuntu"
VERSION_ID="23.10"
VERSION="23.10 (Mantic Minotaur)"
VERSION_CODENAME=mantic
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=mantic
LOGO=ubuntu-logo

$ snap --version
snap 2.61.1
snapd 2.61.1
series 16
ubuntu 23.10
kernel 6.5.0-14-generic

$ dotnet workload install maui-android
Unhandled exception: System.IO.IOException: Read-only file system : '/snap/dotnet-sdk/228/metadata'
at System.IO.FileSystem.CreateDirectory(String fullPath, UnixFileMode unixCreateMode)
at System.IO.Directory.CreateDirectory(String path)
at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallerFactory.CanWriteToDotnetRoot(String dotnetDir)
at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallerFactory.GetWorkloadInstaller(IReporter reporter, SdkFeatureBand sdkFeatureBand, IWorkloadResolver workloadResolver, VerbosityOptions verbosity, String userProfileDir, Boolean verifySignatures, INuGetPackageDownloader nugetPackageDownloader, String dotnetDir, String tempDirPath, PackageSourceLocation packageSourceLocation, RestoreActionConfig restoreActionConfig, Boolean elevationRequired)
at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallCommand..ctor(ParseResult parseResult, IReporter reporter, IWorkloadResolverFactory workloadResolverFactory, IInstaller workloadInstaller, INuGetPackageDownloader nugetPackageDownloader, IWorkloadManifestUpdater workloadManifestUpdater, String tempDirPath, IReadOnlyCollection`1 workloadIds)
at Microsoft.DotNet.Cli.WorkloadInstallCommandParser.<>c.b__6_0(ParseResult parseResult)
at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)

[soma-kurisu]

I've tried a few suggested workarounds from the snapcraft forums (see #1 for an analogous layered phyton problem), but those won't fulfill our expectations (- that's mainly because setting snap's environment variables SNAP_DATA and SNAP_USER_DATA target according to #2 a different purpose).

Another (good looking but kinda hacky) workaround suggests bind mounts on top of snap's read only filesystem. See #3 for a permanent configuration on systemd based setups utilizing the 'current'-named directory link (in dotnet's case /snap/dotnet-sdk/current).

Currently I can not afford spending more time on this. Maybe @joeloff or @leecow can iterate on following question: will additionally installed dotnet workloads and tools survive dotnet patches?

In the meantime I recommend #4 to run MAUI apps on Linux.