There is no way to contact snap package developer

Bug #1624829 reported by Ben Aceler on 2016-09-18
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Snapcraft
High
Unassigned
Snappy
High
Unassigned
Software Center Agent
Undecided
Unassigned
snapd
Undecided
Unassigned

Bug Description

This must be a wishlist, I think.

The idea is, that if a user downloaded a snap package and this package contains some bug or something that user wants to contact the snap creator, snap does not contain any information about snap creator at all.

As far as I understand, there is no contact information field in snapcraft.yaml, and snap command does not have the info also.

So, if there is a bug or wish in the snap package itself, the creator of the package will not know about it.

Daniel Fore (danrabbit) on 2016-09-18
affects: snap-elementary → snappy

I think contact metadata would be super useful. Why not just allow a
URL, which could be mailto: or an https:// for a bug tracker?

Mark

Michael Vogt (mvo) on 2016-11-30
Changed in snappy:
status: New → Triaged
importance: Undecided → High
Michael Vogt (mvo) wrote :

Added a snapcraft task. Looks like what we need is:
- allow a "contact: $URL" field in the snapcraft.yaml that gets propagated into snap.yaml
- make `snap info <pkg>` display this new field

We could brainstorm is there is a better option than "contact:" but I can't think of one right now.

Jamie Bennett (jamiebennett) wrote :

contact is intuitive enough.

Changed in snapcraft:
status: New → Triaged
importance: Undecided → High
Sergio Schvezov (sergiusens) wrote :

We specifically removed the `vendor` entry to make `snapcraft.yaml` really generic and decided that the place to hold this information would be the store (just as you can grab the publisher information)

Changed in snapcraft:
status: Triaged → Invalid
Sergio Schvezov (sergiusens) wrote :

And in such case, the store already holds contact information, look at this snap as an example https://uappexplorer.com/app/minetest-luk3yx.luk3yx

If we are going to make an improvement I'd allow to have the store fallback to a default per publisher contact information field if the specific snap lacks one (which is going to be the case for most as contact information per snap is only set on the store front, which we can of course work on with store folks as well).

Using the store is fine - let's just make sure that snapcraft can update
this from the CLI.

Pointing people to the web interface feels like work, whereas being able
to say "snapcraft update mysnap <email address hidden>" feel quick
and purposeful to our developer audience.

Mark

Mark Shuttleworth (sabdfl) wrote :

Further on this, let's make sure that 'snap info' and the website page
both make reference to 'snapcraft update'.

Mark

Leo Arias (elopio) on 2017-01-04
tags: added: store
Changed in snapcraft:
status: Invalid → Confirmed
Michael Vogt (mvo) wrote :
Changed in snappy:
status: Triaged → In Progress
Michael Vogt (mvo) wrote :

@sergio: we discussed this today in our standup and Gustavo suggested that we should support a "contact: " field in snap.yaml/snapcraft.yaml instead of purely relying on the store. This is similar to description or summary. Lets discuss further if you have concerns about this approach.

On Fri, 6 Jan 2017 13:55:37 +0000, Michael Vogt wrote:
> @sergio: we discussed this today in our standup and Gustavo suggested
> that we should support a "contact: " field in snap.yaml/snapcraft.yaml
> instead of purely relying on the store. This is similar to description
> or summary. Lets discuss further if you have concerns about this
> approach.

The only real concern I have is we purposely remove the `vendor` keyword for snapcraft.yaml to be generic.
That is, for someone to be able to for a project with a snapcraft.yaml and just build it and push it. This however depends on the branching feature to just work. If this is indeed not happening anymore then my point is moot and snapcraft.yaml's become "owned".

--
Sent using Dekko from my Ubuntu device

I would prefer this to be in the store, to enable it to be managed
independent of specific revisions.

For local snaps, you don't need a contact. You only need it for snaps
you got from the cloud, which is the store.

Mark

Michael Vogt (mvo) wrote :

Thanks for your input Mark! Just to clarify (I think I did not express myself well before). The idea would be that both the store would carry the same "contact" information as meta/snap.yaml. It would just be also in snap.yaml so that its inline with summary/description.

One nice aspect of adding "contact:" to snap.yaml is that it would be available even for snaps that get installed via a OOB mechanism (not directly from the store but with full assertions). By having it in the snap.yaml we have the "contact:" and know that its valid (because the hash of the snap is matched by a assertion). But I'm fine implementing it store only of course.

Kyle Fazzari (kyrofa) wrote :

Any progress on this? Personally I just want the "support URL" I set in the store to be shown somewhere.

Michael Vogt (mvo) wrote :

This has landed now in master and will be part of 2.23. We display a "contact: " field in the snap info output that is set on the store side.

Changed in snappy:
status: In Progress → Fix Committed
Changed in snapd:
status: New → Fix Committed
Kyle Fazzari (kyrofa) wrote :

Thanks Michael! Currently all I see store side is the "Package website (optional)" and "Support URL." Is the "contact" field missing store side currently, or will snapd be showing one of those two fields?

Michael Vogt (mvo) wrote :

@Kyle: Yeah, the "contact" field is missing on the store side, please use the support url for now, snapd will use that if contact is missing.

The corresponding store bug to add "contact" is https://bugs.launchpad.net/snapstore/+bug/1666792

Kyle Fazzari (kyrofa) wrote :

Perfect, thank you :) .

Changed in snapcraft:
assignee: nobody → Muhammad Nissaar Mushir Gopee (nssaar)
assignee: Muhammad Nissaar Mushir Gopee (nssaar) → nobody
Changed in snapd:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers