To improve our engagement with the community, we aim to share more frequent updates about our work and upcoming releases.
We are pleased to inform you that we will release snapd 2.66.1 on Tuesday, November 26th. As always, this version is available in the candidate channel for you to test.
This will be the first release of the snapd snap built against core22. It includes important fixes and features we have been working on over the past few months. For the list of changes, please refer to the release notes.
I think it’d better to give feedback here. So, I do have feedback to share about the newly implement desktop-file-ids attribute in the desktop interface in Snapd. But, it only increases the redundancy and might also increase misleading information.
Not sure, how it’s internally handled, but apps already have option to declare desktop files. Now, a desktop file is declared there, but let’s say the user declares a random name in the attribute, that the snap doesn’t provide. What can happen in that case?
We also can’t really test it, until this PR is merged in snapcraft.
But, IMO, instead of redundant declarations, snapd can simply take the allowed desktop file IDs from the apps’ declarations itself. And use that to populate the dekstop-file-ids attribute.
Hello, Thanks for the feedback! It is always highly appreciated.
A snap desktop-file-id must be globally unique to avoid conflicts and also be trusted to avoid snaps misleading users. This why desktop-file-ids can only be set on the snap-declaration assertion level from the store through a public store request and not be auto-populated.
OTOH, the snapcraft.yaml app/desktop entry doesn’t actually map to the generated snap.yaml that snapd understands, AFAICT it is just a directive that tells snapcraft to copy the specified desktop file to the meta/gui directory which snapd scans/copies during installation, Please correct me if I am wrong.
I hope I have answered your questions, Please let me know if something is not clear.
