Having tried my best to avoid compromising any of a dozen ubuntu 16.04 systems with the snap system & packages, I decided to try and install the VLC 3.0 (snap) release on an Xubuntu 16.04 platform. Result, a ‘TF-Disaster’.
Two discreet versions of VLC running on the same system, each apparently oblivious of the other. An entirely new installation paradigm, which appears to run the snap installed version of VLC under some other user identity than the one launching the app, in its own ‘snap-rooted’ location. This, in turn, makes it impossible for VLC-snap to find sub-directories on an array of FUSE/sshfs drives, containing a large media library. Meanwhile, VLC.2.2 is working just fine (because VLC-snap doesn’t even know its there).
And here’s the worse news: apparently VLC has decided to phase out its Debian/Apt installation system (which works), in favor of yet another attempt to impose someone’s grand-solution on the entire Linux community, without having to do the minimum necessary due-diligence this radical departure from standard-practice demands.
I’d be the first to acknowledge the need to address the packaging problem snap purports to fix. This just made the situation exponentially worse.
If I understand correctly, you are having two problems:
you installed a snap-based package and expected it to remove an apt-based package
your snap-based package does not find your fuse+sshfs drives
For (1), simply uninstall the package you don’t want. I understand you might’ve liked snapd to remove the apt-installed package; many more people would find that wrong, so we’ve not implemented that.
For (2), where are the drives mounted? Have you connected the removable-media interface? did it help?
As the snap packaging of VLC is officially maintained by the VideoLAN team you should probably contact them directly instead.
It should be possible for the snapped application to access the drives if it is mounted under the user’s home directory and /media or /mnt if the removable-media interface is connected.
In retrospect, it might have been better to approach the situation with an open mind and without the hyperbole. If you have a genuine desire to get this working it might be worthwhile taking some time to learn about the confined environment and seeing whether the removable-media interface is helpful to you. If not, your use case could be used to help make snapd better.
I spent the first 20 years or so of my career struggling to overcome the relentless stream of defective, poorly documented, inefficient – but nonetheless, ‘industry standard setting’ software, Microsoft used to protect its monopoly over desktop computing, and hobble competitors attempts to produce superior desktop alternatives to their cash-cow products. Had it not been for Netscape, Google-Search, Mozilla (as well as numerous below-the-radar open-source developers), and first-and -foremost, Linux, I shudder to imagine where this industry would be today.
When industry leaders get it in their heads that their vision of “how it all should work” is superior to everyone elses, and they are in a position to impose that vision on large numbers of people (usually driven in part by a ‘windfall profits’ fantasy), they often do, and when they do it in the open-source arena, it can have very deleterious effects on the ecosystem. Until recently, I thought Ubuntu was a safe-haven from that kind of thinking. The Unity desktop was strike one, Systemd strike two, and Snap strike three. Is there a ‘Ubuntu Pro’ version coming next?
Since I have no choice, I’m wading into Snap, initially just to see if there’s a way to excise a working set of binaries that can be situated outside of the snap container. Once I get a bit more familiar with whats going on, maybe I’ll be able to figure out why VLC isn’t seeing the ssh/fuse volumes. Its entirely possible the source of the problem is with VLC’s construction of the snap install. If I find a fix, I’ll certainly report it back.
