Fork-and-rename-me: What to do when the "preferred upstream name" is already taken?

I’m currently packaging the GTK+ UVC Viewer a.k.a. guvcview, however when I tried to register the snap name guvcview according to the snapcrafters/fork-and-edit-me template task I was told that the snap name is already taken, what is the proper way to deal with this problem?

you could just namespace it (adding -foo to the name):

$ snap find tinyproxy
Name            Version  Developer  Notes  Summary
tinyproxy-snap  0.2      garywzl77  -      a light-weight HTTP(S) proxy daemon for POSIX operating systems.
tinyproxy-ogra  1.8.3    ogra       -      very tiny proxy server

No. Please don’t do that. It looks awful, adds tautology and makes a mess when we want to transfer the snap to upstream. I would strongly recommend people stop doing this.

If a name is already taken, it may actually be because we pre-registered all the names to prevent people grabbing them.

You can file a dispute, snapcraft register <foo> gives you a link to facilitate that. Do that and we can review and approve. Ideally you’d push the changes to the upstream project, and if accepted we can transfer ownership to them.


The current snapcraft register prompt actually discourages packagers to file a dispute:

$ snapcraft register guvcview

We always want to ensure that users get the software they expect
for a particular name.

If needed, we will rename snaps to ensure that a particular name
reflects the software most widely expected by our community.

For example, most people would expect ‘thunderbird’ to be published by
Mozilla. They would also expect to be able to get other snaps of
Thunderbird as 'thunderbird-$username'.

Would you say that MOST users will expect 'guvcview' to come from
you, and be the software you intend to publish there? [y/N]:

It should have an exception clause for the packagers that are willing to work with the upstream to take the upstream name.

1 Like

Also, I’d like to say that it will cause a problem when the upstream actually register the name in the first place, just in case of keeping others from taking it. We should probably insert a “Notify upstream for Intent-To-Package” task before the name-registering task so that upstream will not be frightened by the namespace taking(like left-pad).

Any way to know which name is pre-registered for reservation and which is registered by a third-party?