Etcher: RPM packaging for Etcher, repo in general

[ferdnyc]

lsb required by balena-etcher-electron (please don't)

Update: Fixed in #3140

Please don't Require: lsb when packaging Etcher. On Fedora that forcibly pulls in a bunch of unnecessary redhat-lsb subpackages, _and_ the supremely useless qt3 package, because Qt 3.3 is inexplicably part of the LSB.

Plus, the RPM installs Etcher primarily into /opt, which isn't even provided by the redhat-lsb package(s). (It's owned by the filesystem package. As are the other directories used in the package, like /usr/share/applications and /usr/share/icons/. /usr/share/icons/hicolor is owned by hicolor-icon-theme which might make sense as an additional dependency, if you wanted to be maximally paranoid about prerequisites. In practice there's no real need to require hicolor-icon-theme, though.)

Distributing the .repo config as a -release package

Regarding the repo information, rather than having users download an etcher-rpm.repo file and manually install it into /etc/yum.repos.d/, the current norm for external repos is to package the repo configs as an RPM of their own. By convention that package has the filename repo-name-release-version.noarch.rpm. The RPM should contain:

• /etc/yum.repos.d/etcher.repo
  ("etcher-rpm" is a silly name, that it's an RPM repo is implicit)
• /etc/pki/rpm-gpg/RPM-GPG-KEY-balena-etcher
  (This should be a copy of the key used to sign the RPM packages.)

Packaged that way, you'd want to adjust etcher.repo with these configs:

gpgcheck=1
repo_gpgcheck=0  # Unchanged to avoid a chicken-and-egg problem installing the packaged key 
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-balena-etcher

And start signing the packaged builds of Etcher (but not the -release package).

The install instructions can then be replaced with the much simpler:

sudo dnf install https://rpm.etcher.io/balena-etcher-release.noarch.rpm

...DNF will download and install the repo configs, and the first time it needs to validate a signature it'll ask permission to import the key directly from the file in /etc/pki/rpm-gpg/.

Even if you don't switch to signed RPMs, distributing the /etc/yum.repos.d/etcher.repo file packaged as a -release.noarch.rpm is still recommended. It lets the repo config file be installed and managed by DNF, which is more convenient for both endusers and repo maintainers.

(You even gain the option to update the configs in the .repo file and/or add additional .repo files to /etc/yum.repos.d/, simply by releasing a new version of the balena-etcher-release package. Any users who installed the .repo file using the -release RPM, instead of manually, will automatically receive the updated configs as a standard package update. There's no way to distribute updates to a .repo file that users downloaded using wget and installed by hand, you'd have to convince them all to manually download an updated file and copy it into /etc/yum.repos.d/ in place of the previous config.)

See e.g. the RPM Fusion install instructions for examples of -release packages used to distribute .repo files and associated metadata.

[lurch]

I wonder how much of this is within Etcher's control, and how much is handled within electron-builder and/or fpm ? :man_shrugging:

[ferdnyc]

I wonder how much of this is within Etcher's control, and how much is handled within electron-builder and/or fpm ?

Hmm, that's a fair question, if they're using those tools.

The -release package thing would still be _totally_ in their control, since it's an entirely separate suggestion for organization of the repo metadata and configs. All of that is totally unrelated to the Etcher package builds. (Even package signing can be done after-the-fact by running rpmsign on the .rpm files themselves, no matter how they get built.)

The dependencies the Etcher RPM is built with, that's maybe not so easily changed. But if some tool is assigning lsb as a default dependency, it's very likely _really_ out of date, and may be applying other Worst Practices for RPM packaging as well. Could be worth upgrading the toolchain, if possible, or if it's stuck that far in the past, reevaluating whether it's still the right tool for the job.

[lurch]

Looks like at least part of this has been addressed in #3140

[ferdnyc]

Ah, yes, looks like the lsb dependency is history. That's good news, thanks!

[lurch]

You need to thank @zvin , not me! :smile: I'm not an Etcher developer, just a "helpful Etcher user".

[ferdnyc]

I will praise the messenger as I see fit!

(But thanks _also_ to @zvin , absolutely.)