Comment 11 for bug 1603481

I was under the misguided impression that 'aliases' would still be of
the form <snapname>.<alias> and that top-level commands would be of
the form <command>.

On Wed, Dec 14, 2016 at 9:34 AM, John Lenton <email address hidden> wrote:
> Joe, can you explain how you understand them to be different?
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1603481
>
> Title:
> multiple binaries from the same package
>
> Status in Snapcraft:
> Fix Committed
> Status in Snappy:
> In Progress
>
> Bug description:
> This isn't a bug, but rather an architectural concept issue.
>
> If I want a snap to seamlessly replace an existing system package, it
> only works if what I am snapping has a single binary. An example would
> look like this:
>
> I have some compression library (for sake of example, named 'tiny')
> that provides pack and unpack type binaries. Users are used to typing
> (and all documentation refers to) `tiny` to compress and `untiny` to
> uncompress. I can't replicate this behavior with a snap, the best I
> can get is:
>
> /snap/bin/tiny
> /snap/bin/tiny.untiny
>
> I understand the reason for this, to avoid conflicts between multiple
> packages, but perhaps there is a way to do this better. Perhaps some
> sort of metapackage to claim the other namespace? Have 'tiny' be the
> package and 'untiny' be a claimed metapackage so both binaries can
> exist without a prefix?
>
> In the real-world, I am attempting to package OpenStack in snaps and
> this issue would prevent people from following existing documentation
> for management of OpenStack. With a solution to this problem it could
> truly be a seamless experience to use snappy instead of packages.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapcraft/+bug/1603481/+subscriptions