Snap binary names conflict with Ubuntu Snap

[mbbroberg]

This one is tricky, so I'm going to be thorough in the explanation.

Problem

Exploration of the root cause of #1294 by @nanliu has found a noticeable conflict in naming conventions between the Snap Telemetry project and Ubuntu Snap.

• Current naming of snapd and snapctl conflicts with snap/snapd package shipped by default starting Ubuntu 16.04 and snapctl starting 16.04.1
• snapctl/snapd conflicts with ubuntu's binaries for Snappy packaging tools
• Ubuntu intends to distribute Snappy to a variety of Linux OS (either in the default repo, or supplementary packages)
• Snappy packages are called "snaps"

Impact

• Immediate: Snap does not install on Ubuntu 16.04.1 or greater using our current packages
• long term: Snap may not install on a large number of Linux distros as Snappy becomes standard

Possible Solutions

• Use absolute path /opt/snap/bin/{snapctl,snapd} << Not preferred due to Cons

  • Pro: no change to snapd/snapctl
  • Con: Confusing for new users. Users must understand PATH configuration. Potentially misleading errors like in error: snapctl requires SNAP_CONTEXT environment variable #1294. Search engine result conflicts with Ubuntu Snap/py.

• Single binary snaptel << Nonstarter due to Cons

  • Pro: Avoid need for two command. go get github.com/intelsdi-x/snap just works.
  • Con: Cannot configure file mode appropriately for client/server daemon access. Increases security concerns for production use cases.

• Rename snapd/snapctl

  • Pro: Avoid name conflict in brand and binary form
  • Con: Change to documentation

Conclusion

It's in our longterm best interest to choose a differentiated naming convention for the binaries used in Snap. I spoke with the team at Ubuntu through this bug and IRC.

---

Research

Ubuntu 16.10
Package: snap snapd
Here's a list of files that are most concerning (or could conflict with a snap* name)
/usr/bin/snap
/usr/bin/snapctl
/usr/lib/snap/snap
/usr/lib/snapd/snap-exec
/usr/lib/snapd/snapd
For full list see:
http://packages.ubuntu.com/yakkety/snap
http://packages.ubuntu.com/yakkety/snapd
We also have potential environment variable conflicts with Snap (though this is less risky unless we use Ubuntu snap to package snap-telemetry):
http://snapcraft.io/docs/reference/env
SNAP_NAME: snap name
SNAP_VERSION: snap version
SNAP_REVISION: store revision of the snap
SNAP_ARCH: the architecture of device (eg, amd64, arm64, armhf, i386, etc)
SNAP_LIBRARY_PATH: additional directories added to LD_LIBRARY_PATH
SNAP_DATA: writable area for a particular revision of the snap
SNAP_COMMON: writable area persistent across all revisions of the snap
SNAP_USER_DATA: per-user writable area for a particular revision of the snap
SNAP_USER_COMMON: per-user writable area persistent across all revisions of the snap

Ubuntu also delivered snapd package to arch, debian, fedora, gentoo, opensuse. arch and debian are native packages, with the rest via addon repos.
http://snapcraft.io/docs/core/install
Ubuntu16.04
Package: snapd
Files:
/usr/bin/snap
/usr/lib/snapd/snapd
http://packages.ubuntu.com/xenial/snapd
Package: snap (this is subsequently changed to snap-aligner)
Files:
/usr/bin/snap-dna
/usr/lib/snap/snap
This is a package for http://snap.cs.berkeley.edu/
http://packages.ubuntu.com/xenial/snap
Fedora
snap: a modular system backup/restore utility.
https://apps.fedoraproject.org/packages/snap
command:
/usr/bin/snaptool

man page:
man snap(1)
snapd package name is taken, but not built:
https://apps.fedoraproject.org/packages/snapd
Arch
https://wiki.archlinux.org/index.php/Snapd
Misc
http://hackage.haskell.org/package/snap
http://snap.cs.berkeley.edu/
EMC VNX snapcli command:https://community.emc.com/thread/172890?start=0&tstart=0
Some commands:
RPM: snapper.x86_64 : Tool for filesystem snapshot management
/usr/bin/snapper
/usr/sbin/snapperd

snappy.x86_64 : Fast compression and decompression library
https://github.com/google/snappy

[mbbroberg]

We can focus on calling our project Snap Telemetry since its more descriptive and still vendor neutral. The binary names should reflect that. Talking to other maintainers, we came up with snaptel as a solid option.

So:

• snapd -> snapteld
• snapctl -> snaptel

Let's do some due diligence to make sure this looks good and won't conflict again in the future.

[nanliu]

Some additional context regarding snap packaging changes.

In snap 0.18.0 we migrated the snapd/snapctl binary to /usr/local/bin/snapd/snapctl so it's no longer in conflict with Ubuntu's packages. If this proposal is accepted, we plan to update the snap packages and provide some symlinks to help the migration:

/usr/bin/snaptel -> /opt/snap/bin/snaptel
/usr/sbin/snapteld -> /opt/snap/sbin/snapteld
/opt/snap/bin/snapctl -> /opt/snap/bin/snaptel
/opt/snap/bin/snapd -> /opt/snap/sbin/snapteld
/opt/snap/bin/snaptel
/opt/snap/sbin/snapteld

The https://github.com/intelsdi-x/snap-docker repo will be updated with the same symlink, and we will publish containers to a new docker hub repo. The existing https://hub.docker.com/r/intelsdi/snap/ repo will hold the old snapd/snapctl binaries, and we will use snaptel as the new container name.

[andrzej-k]

Just curious, what were the alternatives to "snaptel"? Starting flame here probably - but I'd like "snapmetrics" better for package and tool name :)

[mbbroberg]

It's a fair question @andrzej-k! The alternatives focused on snap +/- some portion of other parts. "Metrics" is not a phrase we want to stick to since Snap's architecture can (and may) be applied to values beyond metrics.

Naming is never easy, but leaning toward "Telemetry" as the descriptor feels right for the project since it leans to more consistent naming with the website and packaging.

[brharrington]

No strong opinions, I'll just note that my initial reaction to "tel" was telephony rather than telemetry. If I saw the name without other context, then I would likely assume it was something like the tel command or maybe something voip related.

[marcintao]

How about snaptmd? snaptmctl?
This is still close enough to "snap" and close to telemetry or monitoring (snaptmd).

[mbbroberg]

These are always hard problems. Let's work through options:

snaptel/snapteld - definitely fair to think it relates to tel @brharrington. I'm glad you brought it up! I can't think of a way to get around it without getting over 10 characters. If you are aware of both projects, would it be confusing to have both in the box?

snaptele/snapteled - same challenge as above but with a British accent 🇬🇧 . Better or worst?

snaptmctl/snaptmd - proposed by @marcintao. Has the benefit of being shorter. Negative is that it reads like ™️ (Trademark) or Markdown for the daemon and the ctl replacement is a painful set of letters. Also isn't easily pronounced, which is the show stopper for me. People need to be able to talk about the commands without spelling it out.

snapmetrics/snapmetricsd - suggested by @andrzej-k. "Metrics" is not a phrase we want to stick to since Snap's architecture can (and may) be applied to values beyond metrics.

Notes

Our packaging of Snap is snap-telemetry and our website is snap-telemetry.io. Telemetry is a good differentiator of a word.

[lynxbat]

Technically Intel is In-Tel. So kind of like Snap-Tel.

Not really why, but funny coincidence.

[mbbroberg]

^ That was a bonus part of snaptel 😄 . It's worth saying as well: we will NOT name the binary with Intel in the name (like intelsnap) since the project is open source and community-oriented.

[szelmo-zz]

Don't want to multiply number of options here - but today two other have came to my mind:

• snapgo - with the powerfull snapgod for deamon ;-)
• snapup - emphasizing ability to collect metrics quickly and eagerly

Just a two cents before end of the day :)

[andrzej-k]

@mjbrender Thank you for explanation. I'm fine with snaptel 👍

[mattyjones]

Not to thread jack but @mjbrender I am considering bringing this to Debian as well. I would like first class support of it within Debian. In doing this I would like to at least touch base with you about the naming so that is stays consistent. I haven't devoted much time to this as of yet but over the holiday break I was hoping to get something stable into unstable at the least.

[mbbroberg]

Glad to have your input @mattyjones - I didn't see any conflicts within the Debian ecosystem when I searched, but appreciate you checking as well. Curious to hear more about your goals. matthew dot brender at intel. 👍

[mattyjones]

The package name snap conflicts with:

Package: snap
Maintainer: Debian Med Packaging Team debian-med-packaging@lists.alioth.debian.org
Description-en: location of genes from DNA sequence with hidden markov model
SNAP is a general purpose gene finding program suitable for both eukaryotic
and prokaryotic genomes. SNAP is an acroynm for Semi-HMM-based Nucleic Acid
Parser.

With the above I am recommending the Debian package use the name snap-telemetry which will also help to identify its usage. The binaries as of yet should not be an issue due to the above commit.

[mattyjones]

Debian ITP (Intent To Package)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844786

[kindermoumoute]

With the above I am recommending the Debian package use the name snap-telemetry which will also help to identify its usage. The binaries as of yet should not be an issue due to the above commit.

@mattyjones, to sum up the conversation, the package name will be snap-telemetry, with 2 binaries: snaptel and snapteld. Do you see any conflict with that solution?

[mattyjones]

This is the binary for the conflicting package as best I can tell so the above names should be fine.
https://anonscm.debian.org/viewvc/debian-med/trunk/packages/snap/trunk/debian/bin/

I have officially changed the package name in Debian to snap-telemetry, the above link is still valid and can be used for tracking. If anything additional comes up in the process I will open a dedicated issue for the packaging.