FS#50435 - [snapd] - snapd package should not create /snap

Attached to Project: Community Packages
Opened by Jonathan Roemer (pid1) - Thursday, 18 August 2016, 17:36 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 23 February 2017, 04:00 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Timothy Redaelli (tredaelli)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Our snapd package currently creates /snap.

https://git.archlinux.org/svntogit/community.git/plain/trunk/snapd.sh?h=packages/snapd

This is an unnecessary violation of the FHS, as $SNAPS is respected.

We should have a discussion concerning where these would be moved. As per the Fedora package spec, which currently owns /var/lib/snapd/{assertions,desktop,mount,seccomp,snaps}, I believe we should use /var/lib/snapd/snaps.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Thursday, 23 February 2017, 04:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  snapd 2.21-1
Comment by Jonathan Roemer (pid1) - Thursday, 18 August 2016, 17:37 GMT
I should note that we should use /var/lib/snapd/snaps for downloading, and /var/lib/snapd/mount as the final location.

See

https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c10
https://fedorahosted.org/fesco/ticket/1614
Comment by Levente Polyak (anthraxx) - Thursday, 18 August 2016, 19:17 GMT
Well I agree that we should not break FHS and introduce new non-standard root directories no matter how uber-special a piece of software itself feels to be.
If one exception is made, the rule is pretty much useless and potentially any other "special" software gets its own root dirs.

Luckily this case should be trivial to solve.
Also i agree something like /var/lib/{pkg} could be a good place as its meant to be the "Persistent application storage", perfect match for such. :)
Comment by Timothy Redaelli (tredaelli) - Friday, 19 August 2016, 16:11 GMT
The "package" itself doesn't create any /snap directory,I can't see any mkdir inside your linked file):

drizzt@liara ~ % pacman -Qo /snap
error: No package owns /snap
drizzt@liara ~ %

$SNAPS doesn't do that you think, the only environment variable that does almost what you want is "SNAPPY_GLOBAL_ROOT", but it's used for chroot and testing,
changing directory is not supported upstream yet.

The directory is *not* created during install time, but it's only created at runtime, exactly like autofs using the default configuration (it creates /net and /misc).
Comment by Levente Polyak (anthraxx) - Friday, 19 August 2016, 16:27 GMT
well the SnapSnapsDir in dirs/dirs.go could be patched accordingly, the other go files access that property by dirs.SnapSnapsDir
Comment by Jonathan Roemer (pid1) - Friday, 19 August 2016, 17:39 GMT
Yes, we are creating it at runtime, but ideally we would not be doing it at all.

If we are going to be creating a directory at /, it should be in the PKGBUILD and handled by pacman. I apologize if I misunderstood how $SNAPS works. I thought they were unaware of where they were on the filesystem, and that we could handle it through that var.

If /snaps truly is hardcoded, we should work with Fedora and Debian to get this changed upstream.
Comment by Levente Polyak (anthraxx) - Friday, 25 November 2016, 19:20 GMT
any news on this one? Fedora has already rejected shipping /snap and siwtched to have /var/lib/snapd/snap
Patch can be found here: http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/0001-dirs-FEDORA-use-alternate-snap-mount-directory.patch

https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c21

Loading...