The AppStream generator is a service that processes a distribution’s (traditional, e.g. .deb) packages and generates AppStream metadata out of that. That is then distributed by the distro and consumed by software centers like GNOME Software, KDE Plasma and others to display nice listings for available software.
I run the instance of this service for Ubuntu. The generator is built from source there: inside the Juju charm I download all the dependencies and drive the build process myself, and then we use the resulting binaries to generate the metadata. Unfortunately, due to this being a living software project, backports of updated dependencies - including the compiler itself - are often required. In practice it has gotten too difficult and I stopped doing it.
The upstream author requested that I update for the LTS, because there are lots of fixes and features that we don’t have and would make the generated data much more comprehensive and better. I basically said the above, and asked if they could consider making a snap - which happened!
And now it’ll be possible to always update in the future too! Woohoo!
Now this is currently a classic snap. Upstream says there is probably no fundamental reason why this couldn’t be confined, but they and I are concerned that things may not work - even silently - and we need to do some testing before we can be more confident in turning on strict mode. We would hate to find this out after Focal has released, because then it would be impossible to fix the generated metadata (the release is frozen once it’s out and we have no way to push updated indices). Given all this, I wonder if it would be OK for us to use classic confinement for now and explore at a more leisurely pace how we can go strict?
Happy to hear alternatives to receiving this via the store, but if you want to suggest that I do something totally different, I would ask you to please be mindful that I’m quite loaded with various tasks related to making 20.04 happen so I don’t have a very big amount of time - in any event I have to re-work the charm to install from the snap and monitor that it’s working…
Granting classic confinement is a big step - in the meantime, would it be possible to install the snap as devmode since this should give it ‘almost’ classic confinement and once you have the time, then can work towards strict mode confinement?
As long as it works (have not tested that), yeah, that’s fine. What I want to be able to do is install the builds that upstream are now producing, use those, and receive updates to them. Does devmode give me that? Is that something that needs to be granted, too? Because:
laney@disco> sudo snap install --devmode appstream-generator-laney
error: snap "appstream-generator-laney" not found
edit: I probably have to change something in the yaml and re-upload don’t I?
OK yes I figured that out, and I can install with devmode, but then it’s apparently not in the host mount namespace, so /srv isn’t shared and that’s where the charm sets up all the configuration and stuff.
Right, yeah, I get that it’s behaving as designed - so can I achieve what I want to achieve with devmode? Is there an interface that will bind-mount /srv (actually I only need /srv/appstream) from the host for example?
Well just as a temporary thing you could use /var/lib/snapd/hostfs/srv, but that can’t work from non-devmode strict confinement. Is there a reason the thing looking at /srv can’t look at /mnt or $HOME or somewhere like that, or even somewhere in /etc that you would be able to access from strict confinement?
OK fine, you got me to spend the time I was trying to avoid spending on this. I used up a few hours today re-working the charm to put stuff into /home/ubuntu/ instead of /srv and now it appears to be running OK from the snap.
One thing that did most certainly not work was making the ubuntu user have its home directory be /srv/appstream; the snap refused to run then with a weird message about how it couldn’t create a directory under $HOME/snap/ which already did exist. Oh well.
Yes, this is a current limitation of snapd. I’m not sure if it’s helpful, but some people who have home directories elsewhere will bind mount the actual home dir on /home/<username>.
Thanks for getting back to us. The request has been dequeued.
