Closed navnavnav closed 2 years ago
Just started using Bloom with an Uno and a Snap. Just in case others have a similar issue. Regarding .deb package installation, I did the following for ArchLinux:
Using the instructions here, I converted the .deb to a tar.zst package https://ostechnix.com/convert-deb-packages-arch-linux-packages/
sudo debtap -u
deptap Downloads/Bloom-0.4.2-Linux.deb
sudo pacman -U Downloads/bloom-0.4.2-1-x86_64.pkg.tar.zst
Installed with no issues.
Could you consider shipping it as Flatpak in stead?
Thanks for the suggestion, @pavelskipenes
I hadn't heard of Flatpak before, but after taking a quick look, it seems to be quite similar to Snap. In the past, I have considered distributing Bloom via a snap but concluded that there was too much work required to get it to work properly, and it simply wasn't worth the effort.
This is because Bloom requires access to USB devices (debug tools) for which there may be no kernal driver installed. Bloom implements user-space drivers via libusb and libhidapi. But snaps (and apparently Flatpaks) are supposed to run in "sandboxed" environments, where the user must explicitly give permission for Bloom to access each device. IIRC, this is where most of the work was required. There were a number of options but I didn't like any of them. From memory, they were something like:
raw-usb
interface (https://snapcraft.io/docs/raw-usb-interface). This means that someone at Snapcraft would have to explicitly approve Bloom for "auto connecting" to that interface (so that Bloom could access the USB devices without requiring explicit permission from the user, each time)Simply put, Bloom wasn't designed to run in a "sandboxed" environment. All of the options listed above either involve too much hassle or would lead to frustrations among Bloom users. And I fear that other issues may arise when running Bloom in a "sandboxed" environment. From what I remember, Snapcraft had a quick fix for this, where users could request that a specific snap only be run in the "classical" mode. But this has to be explicitly requested by the user when they install the snap. And there didn't seem to be a way to configure the snap to require "classical" mode, so users could install it incorrectly and then face issues when trying to run it. All of this would result in too much hassle.
So that's why I decided against building a snap for Bloom. I'm not sure if Flatpak has the same problem, but after a quick glance, they do seem to follow a similar approach. And even if we can get past the USB device permissions, there is still that concern that users may face other issues when running Bloom in a "sandboxed" environment.
I think for now, I'm just going to stick to the old-school packaging approach. It comes with its own set of complications, that's for sure, but I know how to get around them and it's not too much hassle after the first time. I may reconsider this decision in the future.
BTW, I plan on looking into building an RPM package for you this weekend. I will keep you updated via this ticket 👍🏽
Thanks!
Hi @pavelskipenes,
I've just shipped an RPM package and updated the website. I have tested the package on Fedora 35 and it works well. Please download the RPM via https://bloom.oscillate.io/download and let me know if it works on your distro. I will close this ticket once I've received confirmation from you.
Thanks
@navnavnav I'm not on Fedora :/ I've "installed" it by unzipping the .deb
package. Didn't manage it to run just yet but I assume it's because of configuration mismatch with my hardware. Anyway it's not related to this issue :)
@pavelskipenes You don't have to be on Fedora. You can just download the RPM via the "Other" option and install it as you normally would:
But given that you've apparently installed it manually, I will now close this ticket.
Bloom is currently distributed via a Debian package. Users of non-debian based distributions are unable to install the prebuilt Bloom package. They are forced to build Bloom from source, which isn't ideal.
It would be nice if we could maintain an RPM package along with a Debian one.
I probably won't begin work on this until there is evidence of demand. Please add a reaction or leave a comment on this issue, if this is something you want.