Snappy installed manpages aren't accessible through man

Status changed to 'Confirmed' because the bug affects multiple users.

I guess this is an instantiation of a greater architectural challenge:
Snap is meant to separate applications together with their respective dependency chains, but is augmenting a platform where there is a strong tradition of inter-package integration through the filesystem namespace. You will reach manpages, fonts, language specific packages, etc. through well-defined paths in the filesystem. This is (I guess) solved for the dependencies for the snapped application, but how do you/can you provide those filesystem-based services from a snap?
Are there any discussion of this greater issue somewhere?

Yeah, I'd totally like that feature as well.

As an outline of one potential solution:
- the path "inside" the snap is the usual man page paths, but relative in there.
- if man would just know that the binaries /snap/bin/<snapname>.command can be found in /...path..to..snaps/... the hosts man could pull it in
- using the function of MANPATH_MAP of /etc/manpath.config could do that (maybe via a /etc/manpath.config.d then)

But just "as is" this would break confinement - so we very would need a proper interface designed for that.

In general this might only be reasonable for classic, there snapd could provide such a wrapper.

Just wanted to document the thoughts so far - thanks to #snappy channel for some discussion already.

Surely has to be discussed by people with more insight into the snap environment, but it would be a really nice feature to have in classic environments.

You don't need to set MANPATH here, and almost certainly shouldn't. man automatically infers manpath elements from PATH: for PREFIX/bin, it automatically tries PREFIX/man, PREFIX/bin/man, PREFIX/share/man, and PREFIX/bin/share/man. So whatever bit of snap puts /snap/bin/foo in place should simply also put /snap/man/man1/foo.1 in place, or similar.

(Previous comment is with my man-db maintainer hat on, by the way.)

Thanks a lot Colin for that extra insight, that might make the resolution of this issue much easier.

And while placing the manpages in those directories they could be prefixed with the snap prefix of multi-app snaps.

So if you snapp has:
 foobar.foo
 foobar.bar

But the native build systen only build foo.1 and bar.1 - on all the mapping and file organization we do to make a snap available one could also map those to foobar.foo.1 and foobar.bar.1 in the directories suggested by Colin.

I'll try to give this a shot when I look at my snap again anyway next time.
Need to check if that works as is, or needs some extra snapcraft bits to get the stuff placed this way.

This could use some attention. With talks of migrating some debs to snaps, it's come up again that snaps don't have manpages, which is a regression.

I've uploaded man-db 2.8.1-1 to Debian, and that will shortly be synced into bionic; this uses a combination of strategies involving seccomp and AppArmor to confine the processes that parse manual pages.

How much do we care about backporting some or all of this to earlier series before allowing snaps to make manual pages available? Considerations here:

 * The AppArmor support is probably relatively easy to backport. It isn't upstream as yet, since AppArmor profiles tend to have a lot of hardcoded distribution-specific paths and I haven't figured out how to sensibly distribute them upstream. It does a reasonable job of protecting some of the most complex pieces, such as /usr/bin/troff, though mainly only in terms of forbidding them from writing to anywhere interesting on the filesystem (they could still open network connections or whatever). It doesn't generally protect components of man-db itself.
 * The seccomp support is upstream (technically as of 2.8.0, but 2.8.1 fixes several serious problems). It uses a pretty restrictive filter for most things, basically just allowing processes to operate on themselves and to do the sorts of things you find in data-transforming pipes, and a slightly more permissive filter that allows limited file creation for the various groff processes that need the ability to create temporary files. It would be very invasive and difficult to try to backport this.
 * This is all proactive hardening: I don't think there's been an actual reported vulnerability in any of the relevant code for 15 years or more. Of course it's possible that that might change if it were a way out of snap confinement rather than an interesting curiosity.

I followed Colin's advice above:

"So whatever bit of snap puts /snap/bin/foo in place should simply also put /snap/man/man1/foo.1 in place, or similar."

I set up my snapcraft yaml to prime:
bin/mysnap
man/man1/mysnap.1

This resulted in the following on the filesystem after installing mysnap:

/snap/
  bin/
    mysnap
  mysnap/current/
    bin/
      mysnap
    man/
      man1/
        mysnap.1

I don't think that through snapcraft we have the ability to push something out directly to /snap/man/ so is it possible that the snap install could copy whatever is in current/man/man1 out to /snap/man/man1/ as part of the install process? Or perhaps man is being changed instead so that it will look into /snap/[snapname]/current/man/man1?

Also, a related discussion is where snap-installed apps place their configurations and how should they be accessed and integrated to host system.

An example of this is a 'youtube-dl' snap (and standard app) whose config as per its man page should be in /etc and ~/.config: "
CONFIGURATION
       You can configure youtube-dl by placing default arguments (such as --extract-audio --no-mtime to always extract the audio and not copy the mtime) into
       /etc/youtube-dl.conf and/or ~/.config/youtube-dl.conf.",

but as I have it as Snapped app they aren't there but somewhere inside Snap-directory structure.

In this regard, I think that Snap-system is not architechturally mature enough to be ueds alongisde host system apps, cause their 'isolation' thingy breaks their normal usage patterns and configurations - and the man pages.

I discussed this with John Lenton and Zygmunt Krynicki a few weeks ago. My notes say that we agreed:

 * ship manual pages under /snap/man in the normal way
 * deduplicate pages by name (i.e. prefixing "<snap-name>.") in the same way as is done for binaries; this means that if you have a binary called <snap-name>.<program-name> with a manual page then "man <snap-name>.<program-name>" will work, which seems most likely to match user expectations
 * add /snap/man → /var/cache/man/snap mapping for index database caches to man-db, so that snap-installed manual pages can be indexed for use by apropos/whatis

I released man-db 2.9.1 today implementing the last of these and also uploaded it to Debian unstable, so it should be in Ubuntu 20.04. Backporting the relevant one-line change (https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb) to earlier Ubuntu series would be possible, but it's not a hard requirement since this is only needed for apropos/whatis, not for simply reading the page using "man".

I believe others are taking care of the snapd side of things; I haven't been keeping track of that.

Any chance this has had some progress in the last few years? I recently filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2009738 without knowing that this was a limitation of snap and not just an oversight by the lxd team.

Thanks