Linux electron-updater — multiple archs support

[acristoffers]

electron-builder: 19.39.0
electron-updater: 2.13.0
Buildind for Linux x64 and i386 AppImage

Architectures aren't a problem for Windows and macOS because NSIS can generate one executable with both archs and macOS only has a x64 version. However, when building for Linux, I get different executables for x86 and x86_64, but only one latest-linux.yml file. When building for both archs the latest overwrites the first and you end up with x86 app downloading x64 updates or vice-versa.

Given that AppImage can't bundle different architectures together, it would make sense to have different, architecture-dependent channel.yml files, like channel-linux-x64.yml and channel-linux-ia32.yml. That would also allow to easily add other archs, like armv7 for Raspbery Pi, and would not need to change the way those yml files are parsed.

From what I see, two files need to be changed:

electron-builder/packages/electron-builder/src/publish/updateUnfoBuilder.ts

Line 112 in 3143269

const updateInfoFile = path.join(dir, `${channel}${packager.platform === Platform.WINDOWS ? "" : `-${packager.platform.buildConfigurationKey}`}.yml`)

electron-builder/packages/electron-updater/src/main.ts

Line 58 in 3143269

function getChannelFilePrefix() {

But I might be wrong, as I'm not familiar with electron-builder source.

[develar]

Interesting question.

We do use OS name as prefix and generate different update files to simplify building — ability to build on different OS in the same time and do not worry about file merging.

But in case of Arch — I am not sure that we should use prefix. I think it will lead to complication. On another side, mostly all fields in the file will be changed and so, the question is — for what we need to use one single file? Why not use Arch prefix, especially because it corresponds to our initial design and idea?

Need to think about it :)

Yes, it seems only these 2 places should be changed.

[acristoffers]

To me it seems that the file-per-architecture is the best one: you can keep the parallel build, don't have to change the yml file format and only makes a breaking change in one platform.

Side question: why do you use the XML api for GitHub instead of the JSON one? For me it seems more natural to use JSON when working with JavaScript...

[develar]

You cannot use json for GitHub — it will be blocked. GitHub doesn’t offer public free API.

[develar]

arch is added to channel file name only if not equals to x64. So, backward compatibility for our users of AppImage update is preserved, and in any case in most cases x64 will be used.