Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

RPM packaging for Etcher, repo in general

See original GitHub issue

<strike>`lsb` required by balena-etcher-electron (please don’t)</strike>

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 <var>repo-name</var>-release-<var>version</var>.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.