Interface auto-connect request for the guvcview snap (personal-files)

store-requests
1

Dear @reviewers, I would like to request the following interface auto-connections for https://snapcraft.io/guvcview according to the process for aliases, auto-connections and tracks.

Interface Name Reasoning
personal-files
read/write access
$HOME/.config/guvcview2 		This is the directory that the application stores its configuration (per video device, e.g. $HOME/.config/guvcview2/video0) (source)

Thanks in advance!

2

+1 read/writing config there is expected behaviour for an application

1 Like
3

+1 from me too. This makes sense for this application.

1 Like
4

While the path certainly makes sense for this application, the personal-files interface is typically about importing files from a traditionally installed application into the snap’s $HOME (ie, $SNAP_USER_DATA/.config/guvcview2). What guarantees does guvcview provide for not breaking a traditionally installed guvcview or vice versa?

+1 for read-only access for install and auto-connection. Deferring vote on write until more information is gathered.

1 Like
5

Given the size of the application I would guess there’s none.

Relevant source:

I would argue that the compatibility between different version/distribution of the same application is rather the upstream’s business though.

6

Yes, but as snap packagers and reviewers we don’t want to break existing environments. Having the snap import and operate independently will be more robust and completely avoid the problem.

-1 for write based on the feedback.

@sparkiegeek and @popey - does the new information impact your vote?

1 Like
7

As @Lin-Buo-Ren alluded to, I believe that guvcview already has to deal with this problem and will need to solve it even if config lived in $SNAP_USER_DATA.

Any issues that crop up will have to be addressed by upstream, and can be dealt with as bugs in the project.

I don’t think it’s our responsibility to protect users from software which breaks backwards compatibility.

My +1 stands

1 Like
8

@sparkiegeek - note that upstream is not handling this and your point is accurate for SNAP_USER_DATA: a snap is free to break itself and these are just bugs in the snap.

However, my point is different and I disagree with your assessment as it pertains to personal-files: ~/.config is where apps installed by traditional package managers and ‘make install’ will look at configuration. We set $HOME to $SNAP_USER_DATA and don’t expose ~/.config/snapname by default for precisely the reason that we don’t want the snap to break the application installed via other means and vice versa (consider a happy user of guvcview that tries the snap, which upgrades the ~/.config dir incompatibly: the user can’t go back to the deb). This is why there is the question of how the software deals with forward and backward compatibility when granting write access for personal-files/system-files, especially since the snap is not coming from upstream (as is this case).

There seems to be confusion on what personal-files and system-files are meant for so I updated the descriptions:

(I encourage all @reviewers to keep those in mind when voting).

9

@pedronis - can you also participate in this conversation?

10

I suppose it’s fair to say:

  • read-only is fine for auto-connection as long as related ownership is clear
  • if write is desired it might require manual connection

It’s clear though that while useful and expedient these new interfaces have opened UX questions that willl need time/thinking to address.

11

3 votes from reviewers and 1 vote from and architect.

2 votes for reading/writing, 2 against.

4 votes for at least read. Granting use of read at this time with ‘config-guvcview2’ as the interface reference. Ie, use:

plugs:
  config-guvcview2:
    interface: personal-files
    read:
    - $HOME/.config/guvcview2

This will allow the snap to import data from existing software.

This is now live.

1 Like