We in the Ubuntu Robotics team are creating a new snap called “ros-installer” that has the goal of simplifying the installation of a given ROS distribution on Ubuntu. However, in order to make that happen the snap needs to be able to alter the host’s sources.list, trust an apt key, install various Debian packages from the upstream ROS repository, and initialize some of the software that it installs. Given that the goal is to actually modify the host, I believe the only way we can accomplish this is with classic confinement.
This doesn’t sound many steps away from sudo curl | bash. I understood we didn’t allow classic snaps which are effectively stores in their own right.
Indeed it’s not. Do we have a policy against this?
That’s not quite what we’re proposing, here. It’s not an entry point to install all sorts of stuff, it has an
install-ros2 command that sets their system up for ROS development. After that one uses
apt like normal.
No, but it just seems like a use of snaps we don’t usually advocate. Typically we put whole, atomic, functional applications inside a snap. Not installers that are classic and as such write all over the filesystem. A
snap remove ros-installer wouldn’t remove much.
Ok. I’m not aware of many previous snaps where we allowed this as classic. The closest I think is
rustup which installs
rust, which is comparable. I think other’s perhaps @jdstrand or @alexmurray should speak up from their point of view.
Agreed. We’re trying to decrease the wall of setup required for ROS newcomers. As far as I can tell, there are a few options:
- Live with the wall of setup (not great but survivable)
- curl | bash (bad ux and not worthy of putting on a website)
- PPA (still requires setup that kind of defeats the purpose of what we’re trying to do)
- Classic snap (better ux, folks still opt into the fact that it can do stuff on your host with
--classic, but really doesn’t fit the snap story that well and might establish bad precedent)