#1614 FHS exception for /snap
Closed None Opened 7 years ago by zyga.

The snapd package that is under review at [1] currently uses the /snap directory for user-visible objects such as application launchers and mounted application images.

Details on the /snap directory layout:

The /snap directory has two goals:

  • It contains mount points for snap images (e.g. /snap/gimp/42/ and /snap/gimp/current -> 42)
  • It contains the /snap/bin directory where application launchers, generated by snapd, are kept (e.g /snap/bin/gimp).

Using the /snap directory has several advantages over alternative choices.

  • The /snap directory layout is very simple, both for users and developers. Unlike various schemes under /usr/share, /opt or /var/lib, the /snap directory contains mounted snap images.
  • The /snap directory is not currently claimed by any standard or distribution so likelihood of clash is very low. As upstream developers of snapd we do want to standardize how snaps are made, installed and used. Using distribution specific locations is at odds to this goal since each distribution may decide on a different set of governing rules.
  • Unlike traditional packages that spread files around the filesystems, snaps are monolithic, read-only bundles. They are not installed partially to /etc, partially to /usr/bin, partially to /usr/lib, partially to /var/, etc. No traditional location is a perfect fit.
  • It is possible that an application's documentation will reference the install location as /snap/ because that is what is used in Ubuntu and others, so even if it works when installed elsewhere, Fedora users might get confused if the upstream documentation says otherwise

Several other distributions, notably Ubuntu, Debian and Arch, have adopted the /snap directory layout. In the interest of simplifying user and developer experience and the non-divergence across distributions we would like to ask FESCo to consider granting a FHS exception to allow snapd to use /snap.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1367825


Replying to [ticket:1614 zyga]:

Responses inline.

The snapd package that is under review at [1] currently uses the /snap directory for user-visible objects such as application launchers and mounted application images.

Details on the /snap directory layout:

The /snap directory has two goals:

  • It contains mount points for snap images (e.g. /snap/gimp/42/ and /snap/gimp/current -> 42)

This belongs in /run/snap/gimp/42, etc. They are non-persistent and are remounted at boot, so they don't belong on /

  • It contains the /snap/bin directory where application launchers, generated by snapd, are kept (e.g /snap/bin/gimp).

These are essentially generated binaries. IMHO they belong in /var/lib/snap/bin.

Using the /snap directory has several advantages over alternative choices.

  • The /snap directory layout is very simple, both for users and developers. Unlike various schemes under /usr/share, /opt or /var/lib, the /snap directory contains mounted snap images.

Perceived simplicity is not an excuse for ignoring the FHS, in my opinion.

  • The /snap directory is not currently claimed by any standard or distribution so likelihood of clash is very low. As upstream developers of snapd we do want to standardize how snaps are made, installed and used. Using distribution specific locations is at odds to this goal since each distribution may decide on a different set of governing rules.

It is not claimed because it's in violation of the FHS - an agreed-upon standard for distributions to decide where content should be installed.

  • Unlike traditional packages that spread files around the filesystems, snaps are monolithic, read-only bundles. They are not installed partially to /etc, partially to /usr/bin, partially to /usr/lib, partially to /var/, etc. No traditional location is a perfect fit.

Actually, from the way they were described on IRC, they absolutely and unequivocally belong somewhere in the /var hierarchy (with the non-persistent parts being eligble for /run, but if you want to stick with /var I won't complain), but you are correct that they don't need to be spread around.

  • It is possible that an application's documentation will reference the install location as /snap/ because that is what is used in Ubuntu and others, so even if it works when installed elsewhere, Fedora users might get confused if the upstream documentation says otherwise

Users generally understand that distributions move things around when it makes sense, such as when upstream makes poor decisions about file locations.

Several other distributions, notably Ubuntu, Debian and Arch, have adopted the /snap directory layout. In the interest of simplifying user and developer experience and the non-divergence across distributions we would like to ask FESCo to consider granting a FHS exception to allow snapd to use /snap.

From the discussion on IRC, it seems that the Debian and Ubuntu location is in violation of their policies and was shoved there outside of process by a trusted "Debian Developer". I suspect that this will be required to change there as well once someone notices. I can't speak for Arch, but I suspect they probably just followed the Debian example without giving it any thought.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1367825

In conclusion: no, please follow the proper guidelines and don't demand special treatment.

sgallagh's response pretty much sums up my thoughts as well.

Update: Pharoah_Atem pointed me at https://bugs.archlinux.org/task/50435 where someone has filed a bug against Arch for the use of /snaps. So I'd say that we're not alone in our insistence on using the FHS and it would be best if the package maintainer approached upstream about solving this for all distros.

Reviewer of snapd here:

In re Debian, according to [http://metadata.ftp-master.debian.org/changelogs//main/s/snapd/snapd_2.0.8+1_changelog the changelog], the initial import entry (2.0.5+1) done by Steve Langasek has the following note:

"Add a further lintian override for the /snap directory so that the
package is not automatically rejected by the NEW queue; this directory
location is certainly subject to discussion for Debian, but let's have
the discussion rather than blocking the package at the archive level."

This implies that policy was bypassed to be revisited later, though I'm not sure whether it will be, or even if it was fully reviewed for import into the Debian Archive.

Replying to [ticket:1614 zyga]:

  • Unlike traditional packages that spread files around the filesystems, snaps are monolithic, read-only bundles. They are not installed partially to /etc, partially to /usr/bin, partially to /usr/lib, partially to /var/, etc. No traditional location is a perfect fit.

Seems like /opt/snap would be a better fit?

During the 2016-08-19 FESCo meeting it was agreed to defer a decision on this. I'm going to reach out to debian, openSUSE, and Arch (potentially others) to try and come to a collaborative agreement on approach so that we're following what other community distros are doing.

[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LILNIZPWP7BXOECFSRZCDFNVS7DKT4FK/ 2016-08-19 FESCo Meeting Minutes]

Replying to [comment:6 catanzaro]:

Replying to [ticket:1614 zyga]:

  • Unlike traditional packages that spread files around the filesystems, snaps are monolithic, read-only bundles. They are not installed partially to /etc, partially to /usr/bin, partially to /usr/lib, partially to /var/, etc. No traditional location is a perfect fit.

Seems like /opt/snap would be a better fit?

In order to do this, Snap devs should register "snap" as an LANANA provider name. See https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html

For whatever my opinion is worth here (I suppose with it and $3 I could buy latte), that does seem like the right thing.

I may not be at today's meeting -- if so, please count me as -1 on this if it comes up for a vote.

We rejected this exception during the last meeting:
* REJECTED: FHS exception for /snap (9:+ 0:- 0:0)

Login to comment on this ticket.

Metadata