search

endlessm / electron-installer-flatpak

Create a flatpak for your Electron app
MIT License
59 stars 17 forks source link

Fix name of x86_64 arch #3

Closed malept closed 7 years ago

malept commented 7 years ago

Flatpak files/repos use x86_64 to denote 64-bit x86 architectures. I assume all of the amd64 references were left over from electron-installer-debian.

It was mostly kind of odd seeing amd64 in one place in the readme, and x86_64 in another place.

mattdangerw commented 7 years ago

@malept looks good thanks!

Just to double check though, is x86_64 going to be easier than the node style x64 for the packaging step for things like electron-forge? In the flatpak-bundler package this is built on we translate from node style arches to flatpak ones if necessary, so either will work.

malept commented 7 years ago

In the flatpak-bundler package this is built on we translate from node style arches to flatpak ones if necessary, so either will work.

Oh, I didn't realize that. I think that means that I can get rid of some very similar code.

I think it makes more sense in the electron-installer-flatpak docs to use the Node-style arches in the examples, and mention that they will automatically get converted to the flatpak equivalent.

mattdangerw commented 7 years ago

@malept pushed a change with the node style arches, so I'm closing this PR. Keep coming with any changes needed for electron forge! Glad this is getting used.

malept commented 7 years ago

@mattdangerw Just so I'm clear, as of #4, the filename will contain the node-style arch instead of the flatpak-style arch? If that's the case, isn't that inconsistent with how other flatpak packages are named?

mattdangerw commented 7 years ago

@malept yeah, if you use a node style arch, the default output name will contain the node style arch. If you use flatpak style arch, output name will have the flatpak style arch. Both should work. You can also supply your own rename function before generating the output name.

The bundled flatpak will have the actual arch stored as metadata. So flatpak install --bundle myapp_x64.flatpak would work just fine.

The standard for flatpak distribution is to host a flatpak repo with any apps you care to distribute. That repo can support as many arches as you are building your app for, and the end user doesn't need to think about arch when installing.

But distributing an app as a single file totally works as well. LibreOffice is an example of someone putting up a single file format, though they don't put any arch in the download name (https://www.libreoffice.org/download/flatpak/). You can also import a single file flatpak into a flatpak repo if you so desire.

Hope that makes sense. Ok with moving back to suggesting flatpak style arches in the docs. Not sure outputting a file with a different arch name then was specified by the caller would be very intuitive, and would require exposing the node -> flatpak arch function in flatpak-bundler as public api.

malept commented 7 years ago

@mattdangerw That makes sense.

I think for Electron Forge, I'm going to keep it so that it uses the flatpak arch in the filename (probably by keeping my own mapping, unless you decide to expose your own function as you mention). Otherwise, it will be different from how the .deb and .rpm files are named, and I'm sure I'll get questions/issues about it.

mattdangerw commented 7 years ago

@malept sounds good!

Also planning to add a few options in this project for specifying a flatpak repo path to export to, and a gpg key to sign with, that should make publishing to a flatpak repo easier.

But I image for electron-forge sticking with the "each target will produce a single output file" approach will fit with how the other formats work. So single file flatpak format should be a good fit there.