multiple binaries from the same package
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snapcraft |
Fix Released
|
Wishlist
|
Joe Talbott | ||
Snappy |
Fix Released
|
High
|
Unassigned |
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/
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.
tags: | added: openstack |
Changed in snapcraft: | |
status: | Fix Committed → Fix Released |
I definitely understand the desire, but it's a slightly hard one to solve.
The problem is not technical though, but organizational. Everybody wants every command to be top-level, so offering this would mean moving what is today a flat snap namespace into being a flat application namespace, which would be somewhat unfortunate for the ecosystem.
Perhaps we can do something else to fix the problem, though. We should be able to easily offer a mechanism to put every application name from a specific selected snap in the current $PATH, which means all interactions with those commands would resolve into that snap.
This would have to be a user choice, but might solve the issue you're concerned about.