Base runtime freedesktop-sdk-runtime-19-08

[valentind]

@jdstrand

I then noticed it is shipping:

• squashfs-root/app
• squashfs-root/snap

These are not going to be available to the snap at runtime because the default base template policy does not allow them.

Removing /snap makes the application not run with an error message related to bind mounting /snap. So I think I need to have it.

For /app this was to allow application to bind mount there. This is to allow conversion of Flatpak applications to Snap, since in Flatpak, the application expects to be installed in /app.

However latest version of snapd does not allow to bind mount in /app anymore. The following check has been added:

				switch elems[1] {
				// this list was produced by taking all of the top level
				// directories in the core snap and removing the explicitly
				// denied top-level directories
				case "bin", "etc", "lib", "lib64", "meta", "mnt", "opt", "root", "sbin", "snap", "srv", "usr", "var", "writable":
				default:
					return fmt.Errorf("layout %q defines a new top-level directory %q", layout.Path, "/"+elems[1])
				}

It seems to me wrong that applications are allowed only directories from core runtime when they do not use that. Instead, Snapd should check the list of top level directories in used runtime and remove forbidden directories.

I can work-around that by mounting thing ins /var/app and adding a symlink /app -> var/app.

[valentind]

@jdstrand

• Base snaps shall not use tracks
• The base snap publisher must commit to not breaking other snaps (base snaps undergo additional review-tools checks from removed files and changed ABIs, but the publisher must also commit to being responsive to bugs and regressions in updates to the base snap)

@valentind - can you comment on each of these:

• Will you not request using tracks for this snap?
• Do you commit to not intentionally break consumers of this snap? (Eg, by removing files, changing ABIs, etc)
• Do you commit to be responsive to bugs and regressions caused by updates to the snap?

For the tracks, this is a question I had before. For the Flatpak world, before release we usually release betas for people to test so that we can fix before proper release. Because once we have released we cannot change much, for example we cannot break ABI. The way we do it for Flatpak is that we have a secondary repository so that only application developers and testers can test it.

It would have been nice for Snap to also have something similar. Note that once we get out of beta, we do not release new betas. Only updates to stable. Also note that every release of the Freedesktop SDK (which happen yearly) will have its own runtime on snap. So new features come only yearly an in different runtime. However it would have been nice if that runtime could be published first as beta.

For the second question. No, we will not break anything. Updates will mostly be bug fixes. That is we update software with their minor bug fixes releases, and eventually we back port fixes for software that do not provide those. We have the same requirements for Flatpak. An application that was built with a SDK of a certain release will work with any updated runtime for the same release branch.

I am not sure what kind of commitment you require for responsiveness if newer snapd requires a change in our runtime. We are community driven. So it is hard to say that at any moment there will be someone that will quickly respond. But for sure there will always be maintainers that will accept contribution from community and help deploy them.

[jdstrand]

I just approved r1 of freedesktop-sdk-runtime-2008 in the store and made a change to the review-tools so this will pass automated review with future uploads (ie, it is allowed to be a base snap). This is not yet in production so future uploads will require a manual approval until it is.

Before you promote to stable, I suggest considering pruning some of the files we discussed that make sense to you and your users. If you do, the next upload will not pass due to missing files, but this is straightforward to manually approve once you tell the missing files are ok to drop.

I noticed a freedesktop-sdk-sdk-2008 in the store and rejected it as it was unclear that it wasn’t a duplicate. Please advise if this is in error.

[ilya-fedin]

I wonder how to use that? I tried to specify base: freedesktop-sdk-runtime-2008, but getting that error:

The 'LXD' provider does not support base 'freedesktop-sdk-runtime-2008'

Recommended resolution:
Ensure build-base or base are correct in the snapcraft.yaml file.