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

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!

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

1 Like

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

1 Like

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

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.

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

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

@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).

@pedronis - can you also participate in this conversation?

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.

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