[DEMO] Add Linux repositories via omnipackage

[olegantonyan]

Hi, pulsar devs
I made a tool that simplifies Linux packages building and distribution - https://omnipackage.org - which might be useful for Pulsar
This is how it can look for the users - https://repositories-test.omnipackage.org/pulsar-dev/install.html

This PR demonstrates the code changes in a forked repo that produces pulsar-dev on push to master on GH actions. It is not supposed to be merged, just minimal viable demo. Feel free to close, criticize the idea, etc. If you decide to pull the trigger, I volunteer to support this for a forseeable future.

Why

I use Pulsar since 2014 when it was Atom. Installing it on openSUSE is not pretty:

1. "missing" dependency. The package depends on libuuid, but on my distro this lib is called libuuid1

Problem: 1: nothing provides 'libuuid' needed by the to be installed pulsar-1.132.1-1.x86_64
 Solution 1: do not install pulsar-1.132.1-1.x86_64
 Solution 2: break pulsar-1.132.1-1.x86_64 by ignoring some of its dependencies

It happens because RPM spec has hard-coded Requires:, but actual packages providing those ABIs can be different on different distros;

2. package is not signed:

    Package header is not signed!

pulsar-1.132.1-1.x86_64 (Plain RPM files cache): Signature verification failed [6-File is unsigned]
Abort, retry, ignore? [a/r/i] (a): 

3. there's no auto-update mechanism, so whenever a new version released I need to go to download page

How

Linux already has all the infrastructure to handle these issues, and omnipackage does exactly this:

1. spawn containers for each distro and run rpmbuild/dpkg-buildpackage. This produces native package with all dependencies resolved cleanly for each distro;
2. sign and upload packages to S3-compatible storage which serves as a repository, as a bonus it generates html page with installation instructions (like this https://repositories-test.omnipackage.org/pulsar-dev/install.html);
3. users can select their distro on this page, copy-paste install instructions, and get the package installed with repository that remains, so the next time you publish new version their distro's package managers will pick up the update;

Open Source

Omnipackage is opensource CLI aka glorified wrapper on top of podman/docker, dpkg, gpg and related Linux tools. You bring your own S3 bucket, your GPG key. There's no accounts, registration or anything like that. The demo repositories (https://repositories-test.omnipackage.org/pulsar-dev/) are hosted on my Cloudflare R2 bucket and use my test GPG key. It can run on Github actions or anywhere else where podman or docker can spawn containers.

[Daeraxa]

First of all, thank you for making this PR. I just want to make sure it is known that it is appreciated before I move on as it might now sound like I'm being dismissive or ungrateful.

We would definitely need to decide if this is a route we wanted to go. It is interesting that this has come up now because we have a bunch of issues around our packaging that I've recently identified and attempting to tackle bit by bit...

These are the current issues directly affecting our packages and build process that are the main focus of mine right now.

• The OpenSUSE dependency has been noted in RPM install fails on openSUSE distributions (Tumbleweed) #938 and I plan to submit a fix soon, I just want to kill a few birds with one stone this will be fixed by bumping electron-builder to the latest version.
• Signing I agree is something we should be doing for Linux. I think we missed this because we focused on the more obvious issues in signing for Microsoft and Apple.
• Linux desktop entry file missing intended information #1580
• Linux native packages (rpm, deb) not adhering to best practice and misleading/unused packaging templates #1579
• Built dependencies contain invalid RPATHs - potential security issue (already triaged by team) #1584

This PR seems to be based on the same templates that we don't actually seem to be using right now (in #1579) so we need to make a decision on that issue.

Also we absolutely have to fix this RPATH issue before we start distributing RPMs in repos - I wouldn't feel comfortable in leaving that open.

And I very much appreciate the effort in this PR but its not a call I can make alone, we need to decide in the team if this is something we want to do. The benefit of our current approach is that all of packages are generated from a single script via electron-builder (and yes this is even with acknowledging all of the above issues) which significantly reduces our maintenance and release burden).

And whilst this would reduce the burden around building and distributing our deb and rpm packages we would still have to keep our existing build process for appimages, windows and macOS.

We are also trying to consolidate our various resources right now, removal of our old cirrus build system and migrating other admin services into things we depend on like GCP. If this service requires an S3 bucket to work then I don't think we have one and we would need to investigate if the cost and admin burden would be worth it. (Unless GCP is compatible - not something I'm knowledgeable enough about).

My personal opinion is that we aren't in a position to support this just yet. We need consensus with the team first and I want to tackle these long standing issues by themselves and not all in one big update. My goals as a minimum prereq to this are:

• Fix the openSUSE dependency issue
• Fix the RPATH dependency issue properly by bumping a dependency to a new major version
• Fix and standardise the deb control and rpm spec to best practices
• Fix the desktop file issues
• Sign linux packages

Once the packages themselves are being produced in the correct standard then we can look at whether we wish to move to a dedicated build and distribution service.