did you add layout entries for all these three yet ? (like i said above) did that not work ?
I assume the requester is asking to make the snap actually writing to the directories on the host’s rootfs instead of those accessible in the snap runtime?
In this case the answer is probably “snaps are designed not to write files to the classic system directories, just like you normally won’t make a docker container write logs to the host’s /var/log”.
My 2 cents.
EDIT: Backup my reply at #9 just so it wont be wrongly marked as the thread’s solution:
well, i’m just trying to point out that there is no actual requirement at all to write to these, using a layout is enough and you do not even need to request any review since this is the standard way to make apps like this “just work” without needing manual reviews or any changes to the app in any way … the same goes for the personal-files request , $HOME by default points to $HOME/snap/<snapname>/current/ for all snaps by default. the app has full write access there … unless you need/want to read any existing hosts files for migration purposes, none of the requested interfaces is needed when the packaging is done right …
1 Like
@ogra
OK, I rechecked my snapcraft.yaml and removed all system-files interface related lines. It does work well too as you described.
Now the client still failed to access $HOME/.taos_history after I removed the personal-files interface. I see the original mechanism is to get home directory by “getpwuid(getuid())->pw_dir”, I think it did not get $HOME/snap/ directory. May I know if you would suggest what function should be used here to make both classic and snap to read right location?
Thanks.
1 Like
@Lin-Buo-Ren I do expect the snap can access other locations for data store requires to utilize faster disk or slower disk. Jamesh had suggested to allow users bind mount other locations in earlier reply. I plan to do it later. The first step is to publish the snap with all normal behavior works.
1 Like
Refer The homeishome launcher: Fix snapped apps that (wrongly) referring to the user's real home directory instead of $HOME for a possible workaround.
(Disclaimer: Just released, use at your own discretion.)
Thanks. I already replace getpwuid() with getenv(“HOME”). Now no need personal-files interface also.
@alexmurray
I got the review tool reports pass.
$ review-tools.snap-review tdengine_2.0.2.0_amd64.snap
tdengine_2.0.2.0_amd64.snap: pass
I made a mistake to reject the new revision then clicked manual review again. I don’t know how to make it “without needing manual reviews” as ogra pointed out. Please help to process it or let me know what I need to do.
Thanks @jamesh @ogra @Lin-Buo-Ren @alexmurray a lot for your kind help.
1 Like
I suppose publishing a new revision should do?
I will update the package version to align with the classic package (even including Windows version) release in the future.
Current 2.0.2.0 is aligned with the latest stable version of the classic release. Appreciated it if it can be approved manually.
One more question, My snap will release new version with classic package release accordingly. So should I modify snapcraft.yaml every time then commit to git repo? Or to compose a small script to modify version string before run snapcraft. Can I specify snap version by command line argument?
Thanks,
The snap version is settable via a part’s scriptlet, refer the adopt-info key for more info.
Also refer: Selective-checkout: Check out the tagged release revision if it isn't promoted to the stable channel
Disclaimer: Own product, use with your discretion.
Another question, how to transfer the snap, especially snap name to another account? I uploaded the tdengine snap to store and display my launchpad name as publisher. I need transfer it to another account with my employer’s company name as publisher and make its name verified with a checked emoji.
Refer The store-requests category in the Snapcraft Forum for such matter.
For the “verified” check mark, I believe it is only granted to the (very) high-profile snaps, maybe the @store folks can help.
OK.
New question, as when the user remove a snap, the data files will be removed too. But as a database software, most scenario should keep data files untile the user manually delete them. How I can implement this with snap?
When your snap is removed, a snapshot of its data is created that will be retained for a month:
If a user reinstalled your snap in that time, then the data will be restored with it. It is possible to omit some data from the snapshot through the remove hook, as described here.
There isn’t currently a way for a snap to have data in snap specific system wide dirs persist in place after removal though.
1 Like
Is it possible for a snap service to access a user’s data path via home and removable-media interfaces, though?
Data outside of the snap-specific dirs (i.e. $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA, and $SNAP_USER_COMMON) won’t be touched on snap removal.
A hook won’t be able to access data in individual users’ home directories though, unless it has read: all set on its home interface plug (which will trigger manual review on the store).
It is possible to retain a snap’s data forever?
As the document I linked states, manually created snapshots are retained until they are discarded. It also explains how you can control the life cycle of automatic snapshots via the snapshots.automatic.retention configuration variable (either disabling their creation entirely, or changing how long they are retained).