The same after-install & after-remove scripts are used for deb and RPM packages despite different semantics

[ravicious]

• Electron-Builder Version: I experienced this on 24.0.0-alpha.5, but it's present on the current master (9b265f4) as well.
• Node Version: v16.18.0 (but that's irrelevant)
• Electron Version: 21.2.3 (also irrelevant)
• Electron Type (current, beta, nightly): current
• Target: deb, RPM

electron-builder lets you provide after-install and after-remove scripts which are then passed to fpm. For the deb package, after-install maps to postinst and after-remove as postrm. For the RPM package, after-install maps to %post and after-remove maps to %postun. I verified that by recreating the SPEC file from an rpm package made by electron-builder.

The default after-install script creates a symlink in /usr/bin and the default after-remove script removes the symlink.

The issue is that during an upgrade, deb scripts have different semantics than RPM scriptlets. When a package is upgraded, deb consumers run after-remove of the old version first followed by after-install of the new version. For RPM packages, after-install of the new version is ran first followed by after-remove of the old version. Both behaviors are documented here:

• Debian Policy Manual: Upgrading a package
• Fedora Docs: Scriptlets - Ordering

So far I haven't seen a single fpm issue which would mention that problem.

I ran into that when writing custom scripts which would symlink another binary that's distributed with my app. If you use default scripts, it means that when the user upgrades your RPM package, the symlink to the package will be removed from /usr/bin.

Workarounds

Utilizing args passed to scripts

I'm yet to dive into that but it appears that for both deb and RPM packages, the consumers pass additional args to the scripts (docs for deb, docs for RPM). Through the use of those args, it should be possible to establish whether the package is upgraded or not and thus it might be possible to use the same scripts for both deb and RPM.

Edit: An example implementation of this. after-remove.tpl can skip any operations on the symlink if it detects an upgrade by reading argv.

This has the unfortunate effect that if you ever want to change location of your symlinks between versions, you won't be able to do so.

A custom SPEC file for the RPM package

I'm not sure what the relation is between fpm and RPM SPEC files. However, I noticed that VSCode uses a SPEC file for its RPM target. This allows them to make the symlink during the installation (see microsoft/vscode#142907).

This has a couple of advantages:

• The symlink will be recognized as made by the specific package. Calling rpm -qf /usr/bin/${executable} will tell the user which package made the file.
• Because of the above, there's no need for a separate after-remove script that cleans up the symlink – this will be done automatically by rpm.

However, I'm not sure if there's a command option in fpm that would let you modify the SPEC file to such an extent to enable this. Adding a custom file just for a single target increases the maintenance costs.

---

I'm checking if the issue is still relevant by checking if after-remove.tpl continues to remove the symlink without doing any extra checks.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ravicious]

Still relevant.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ravicious]

Needs investigating if the recent changes to use update-alternatives fix the issue (#7501). I suspect that it doesn't because in rpm's case, after-install will run first followed by after-remove which calls update-alternatives --remove.

Systems with no update-alternatives are still affected by this.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[ravicious]

Might be still relevant.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[ravicious]

Might be still relevant.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[ravicious]

Might be still relevant.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[ravicious]

Might be still relevant.