The traditional way of installing software under Linux, specifically under Debian, has been, to use a package manager which accesses global repositories of software, and sometimes, to use a graphical front-end to the same package manager.
Thus, under Debian the package-manager command-line to install <somepackage> would be:
apt-get install <somepackage>
But, if we have “Synaptic” installed, that is a graphical front-end for the same set of commands, that I’ve come to like and trust. If we do not have Synaptic installed but wish to, then the way to install it from the command-line would be:
apt-get install synaptic
But what has happened in the Linux world is that this method of installing packages has become ‘boring’. There exists software which is not listed in the package repositories, and which Synaptic will therefore also not find in response to explicit searches, but which users will want to install, simply due to the evolution of software. One reason for which this software is not listed could be, that it would be tedious for package maintainers to compile, but another could be, the fact that some software is proprietary in nature, or at least partially so, so that to include it in the open-source repositories may in some cases be illegal.
And so, even Linux users will sometimes seek other ways of installing specific software, which they already know exists. And another way to do so has traditionally been, to compile this additional software from source code. But, sometimes the out-of-tree software we wish to install needs to come in the form of binaries. A recent development in this field has been, the emergence of a software-management system called “Snapcraft“. It’s based on the ‘Snappy’ package manager, that was developed by Canonical.
I’m going to assume for the moment that the reader already understands the existence of security implications, in installing binaries from anywhere except the package manager, together with the official repositories, even when those binaries are to be sandboxed. And I’m not going to explain those in this posting.
One reason for which Snappy exists, is the fact that some of the more-traditional installation scripts, for out-of-tree binaries, needed to make arbitrary assumptions about the organization of the Linux computer, and there are many different versions of Linux, which eventually lead to incompatibilities with the binary software. Their developers have had to make assumptions about how the customer’s computer was configured, and those assumptions will eventually be wrong for some versions of Linux. Snappy can circumvent this limitation, or so its developers claim. Whether it truly can or not remains to be seen, as Snappy is still in its infancy as I’m writing this. It could be that I just jumped in with a fashion trend, which may turn out just to have been a fad, as seen several years or decades in the future.
But this posting will continue on the assumption that the reader has a Debian Linux computer, but that he wishes to install Snappy anyway. Snappy was designed more with Ubuntu in mind, but is also available for Debian Linux.
(Updated 6/15/2019, 14h20 … )
(As of 6/12, 2019 : )
There are numerous articles on the Web, which the reader may find on his own time, and which simply advise the reader to run the command:
apt-get install snapd
Or, to install the ‘snapd’ package using the favourite graphical front-end for the native package manager. Debian / Stretch, aka Debian 9 already has Snappy in its standard repositories.
Instead of just repeating this advice, I’d like to write about some of my earliest observations, from having installed Snappy on the Debian / Stretch computer I name ‘Phosphene’. At first, the Snap daemon / service could not start.
Apparently, ‘snapd’ will also install numerous dependencies under Debian, that I, as a user, was not used to having installed because many of the dependencies are not (yet) standard, and some of those are downright awkward. It will install ‘apparmor’, which is the standard, repository-supplied firewall that Linux users may install as they wish, and that as of Debian Buster – the version which is to follow Stretch – will be installed by default. But it will also install a subsystem, which creates loop-mounts, and which therefore creates a kind of virtual environment under Debian, for Snaps to run on. Mounting virtual hard drives in that way is a feature which the kernel supports, but which needs to be possible in user-space for this software to run, for which reason Snappy makes the assumption that the user already has ‘fuse’ installed and working. This virtual file-system, what it has access to, and what it does not have access to, are intended security features, to sandbox Snaps to some extent.
It all requires ample CPU power and RAM to work properly. And what users like me have found is, that after an initial install, either the Snap service itself, or some of the applications installed through Snap, may not run. And I have overcome some of these hurdles, so that both the service, and an applicable application, are running. Obviously, the user needs to get the service running first. And under Debian / Stretch, what I found was that the service would initially fail to start because it could not find the following file:
The reasons for which this error takes place are:
- What this file provides has by now been moved to ‘/etc/default/locale’. The requested file has not existed for some time.
- The package maintainers have done some thorough work in adapting ‘snapd’ and its dependencies to Debian, but have missed the fact that this file does not exist anymore.
Some of these problems are really due to the fact that Ubuntu, for which Snap was originally designed, has a different structure of system files, from those that Debian has. What I have just done is to create a symlink named ‘environment’, in the directory ‘/etc’, which points to ‘/etc/default/locale’. The following listing shows the result, which should be highlit in cyan, to indicate that it’s not a broken symlink:
dirk@Phosphene:~$ cd /etc dirk@Phosphene:/etc$ ls -l environment lrwxrwxrwx 1 root root 19 Jun 10 22:47 environment -> /etc/default/locale dirk@Phosphene:/etc$
After I created this symlink, the service started just fine. But then, the first time I installed an actual app, the system needed some considerable time to process the request because apparently, the virtual environment into which Snaps are installed needs to be prepared.
Eventually I got the Snap package installed, which is named:
root@Phosphene:/home/dirk# snap list Name Version Rev Tracking Publisher Notes animationmaker 1.3 5 stable artanidos - core 16-2.39 6964 stable canonical✓ core root@Phosphene:/home/dirk#
As the reader can see, to install snaps to the whole system requires root under Debian, and management of the results is by virtue of the command-line only – with no GUI. But I did get “AnimationMaker” up and running, and made some more observations.
- If we are still running the same session within which we first installed Snap, after we have installed our first Snap app, by nature, that app will fail to display in our launcher menu, both under Ubuntu and under Debian. This seems to be due to the fact that the .desktop Files which are included as part of the Snap package, which would make it visible in our launcher and context-menus, are installed to a new location, where the computer was not previously looking for it. And indeed this new location is part of the virtual mount that has been created. A restart of the system should make the entry appear in our standard launcher.
- The .desktop Files in question name Application Categories which might seem misspelled to Debian users, such as the category “Graphic;” . This is not a misspelling, but becomes apparent to users like me, whose categories only include “Graphics;” . The category which the .desktop File names would exist under Ubuntu.
The second problem might be solvable, if we were to edit the .desktop File in question. But in the case of Snaps I don’t recommend doing so, if for no other reason than the fact that the next update to the package will just override whatever editing I have done to the actual .desktop Files. My chosen solution to this problem is:
- To have a ‘Custom Launchers’ sub-menu in my application menu, which I put there using the ‘K Menu Editor’, and which needs to come after all the system-installed sub-menus, but before the Lost And Found sub-menu. If I put a custom sub-menu before any correct, system-installed sub-menus then, speaking from experience, this tends to foul the application menu, in that all newly installed applications will only appear in the menu next, above wherever I inserted my own sub-menu. In past cases, such a situation next required that I keep editing the customized menu, to put newly installed applications ‘back into their correct order’,
- Only ever to create custom launchers in this one sub-menu,
- Next, within ‘KMenuEdit’, to drag the one menu entry from the Lost And Found sub-menu, assuming that is where it landed, into the Custom Launchers sub-menu which I created,
- To Save the edited launcher menu.
In certain cases I prefer to solve such problems in user-space, rather than always to tinker in system- or root- space. The system files are a scary bunch of files, where, if the user does not understand 101% how they work and changes them, he or she could do a lot of damage. But, GUI-based tools to edit menus that do not require root, can only do a limited amount of damage, such as, to cause some funny menus to appear, but on a computer which still works.
Straightening out menus which users misconfigured in their user-space is possible, but just not the subject of this posting…
The Snap which I presently have installed, was not the first I tried to install. Initially, I had installed Snappy, in order eventually to install ‘figma-linux’. This latter application is a sketching, 2D graphical layout, and diagram-editing-system which is meant as a Linux alternative to ‘Sketch’, which in turn is OS/X -only. Figma-Linux would be an ideal example of software worth installing under Snap because it matches the description of such software which I gave initially in this posting.
But the Snap-package installed version of Figma-Linux currently has a known problem, that prevented it from running on my box. Such problems can occur, not because Snappy isn’t running correctly, but because the dev made an innocent mistake in how he linked the binary, after he compiled it. In this case it seems that the executable links to ‘libpng16′ in a location that was available to the dev, but which it cannot find under Snap, even though I have both the 64-bit and the 32-bit Debian packages installed. Further, thinking that this might be due to my machine being multi-arch, I even tried creating a symlink to the multi-arch locations of this library, and placing that symlink into ‘/usr/local/lib’, and then running ‘ldconfig’. In some cases, such manoeuvres can resolve the issue. But in this case the error message when launching Figma simply remained, unchanged, which is also the reason for which I suspect that the dev made an error.
Trying to test a new Snap-install, with any actual package that contains an error like that, might be confusing, but also says nothing bad about Snap. For the moment, I installed Figma-Linux (v0.5.1) using a downloaded .DEB File, as the BB above suggested, and thus it runs fine. And because this explicitly installed package will also not be receiving any routine updates, I edited its Desktop file as I said above, not to do for Snap packages. But, eventually I’ll want Figma-Linux to be subscribed to future updates which its devs push through. And when they do that, they’ll probably also fix that error. And the way to become subscribed to such updates would be to remove and purge the version which came through the .DEB File, after a version more recent than 0.5.1 becomes available, and then maybe, to try installing Figma-Linux using Snap again…
So for the moment, ‘AnimationMaker’ is the package with which I’ve really tested my Snap service.
Even though I did suggest the ‘snapcraft’ URL above, it should be perfectly sufficient to navigate that site, to find snaps to install. There should be no urgent need to install the ‘snap-store’ app itself. This is supposed to be a launchable app to help users choose snap-based apps. One reason for me not to use it, would be the fact that it’s been optimized for the GNOME desktop manager, while I have Plasma 5.
Also, in spite what I’ve blogged recently, the best way to install an app is usually still the package manager. It would only be for the occasional app that’s not available this way, that I’d consider using snap.
(Update 6/15/2019, 14h20 : )
If the reader wants a more formal explanation, of when and why the Snap version of ‘figma-linux’ won’t run, there is An official bug-report, which at the time I’m writing this is marked an “Open” bug, meaning that it’s ‘Unresolved’. This is also known as Issue #40 of the same app, and rather than waiting until there is a new .DEB File being offered, I can also just revisit the link above, until that Bug has been marked ‘Closed’, ‘Resolved’, etc..