Distribution/updates

[hensm]

Best way to distribute?

• AMO for the extension or bundled with the application?
• Squirrel (mac/win)
• Custom install scripts with manual updates

[hensm]

• Handling app update checking/prompting via extension
  • GitHub releases to avoid separate update infrastructure
  • Options page download button triggering browser.downloads.open for installation

[hensm]

• 267c928 macOS package
• e7d1a27 .deb package

[KAMiKAZOW]

For Linux probably the best way would be to set up an Open Build Service repository which supports all mainstream (and some niche) distributions as build targets. A public, free to use instance is running at https://build.opensuse.org/

[hensm]

I've had a quick look. From what I can gather, building this project would be bit more involved on OBS. The dependencies are all npm packages and there's no network access, so I'd have to download the dependencies and manually copy them, I think. Seems like a bit of a kludge.

[KAMiKAZOW]

I'd have to download the dependencies and manually copy them, I think.

No, not necessarily. The dependencies may already be in openSUSE's main distribution or in other repos. In the latter case those packages would only need to be branched into your repository.

Seems like a bit of a kludge.

Not from the user's point of view.

[hensm]

Most npm packages aren't available in distribution repos.

Not from the user's point of view.

I get that, but it's already distributed in a packaged form. The rpm/deb packages will cover most users and anyone using a more niche distribution can download a tarball.

If it was native code, I'd want to avoid cross-compilation, but the node binary used is precompiled and available for a wide range of platforms. The actual packaging can be done on any platform, so it just seems like a lot of complexity for a comparatively small gain.

[KAMiKAZOW]

it's already distributed in a packaged form

But not in a repository, meaning users will need to upgrade manually every time.

Flatpak is not an option in this usecase because of sandboxing, right?

[hensm]

Yep, the sandboxing makes it a non-starter.

I do see your point about updates, though the extension (at least when it's listed on AMO) will update automatically. That provides an avenue for updating the application, since it can trigger downloads. I'm curious as to whether that falls afoul of AMO policy.

The extension is really the primary part and having the application update on its own actually doesn't make as much sense as I first thought. I think it's more intuitive to keep them in sync, even if that means some manual action to install the update package/installer.

[Batcastle]

You could just make an apt repo on the website. If you have an Ubuntu/Debian based distro installed you can install reprepro and use that to make an apt repo locally then use FTP/SFTP/rsync etc to upload the repo to the website. Just make sure you put instructions on how to add it on the website.

Also, I have an apt repo I am willing to put fx_cast in once it reaches a stable release if you want to do that.

Doing something like that will make it so the bridge will be up-to-date at all times, as long as the latest version is in the repository and the user updates their system.

As far as the *.rpm package is concerned, I am sure you can do something similar, I just don't know how considering I far more familiar with Debian-based systems than I am RHEL-based distros.

[hensm]

If it's possible to host an apt/rpm repo on github pages, I'll provide those as download options with the extension bundled with the bridge, rather than having two separate downloads that would end up out of sync.

[Batcastle]

I'm not sure about that. I've never messed with GitHub Pages. However, based on my research it may be possible.

But you would need two repos: one for apt and one for rpm, so that would complicate things for sure. I'll have to do more digging to see what is possible with GitHub Pages and if these repos can be done.