Add a way to export multiple commands

[matthiasclasen]

Add and --export-command=COMMAND option to the
build-finish command, export it under the exported-commands key in the metadata file, and generate
APPID-command shell wrappers for each of them.

Fixes #5395

Untested, and undocumented so far.

[orowith2os]

This feels a bit weird. This means you could end up with something like org.apporg.app-really\ long\ command, right? Wouldn't it be better to have --export-command=command=fullcommand and --export-command=command, so that longer commands could pretty much be aliased without user intervention?

[TingPing]

so that longer commands could pretty much be aliased without user intervention?

You just can't override commands safely. There would have to be some user intervention for them to opt-in to that.

[orowith2os]

You just can't override commands safely. There would have to be some user intervention for them to opt-in to that.

I'm saying that foo.bar.appid-long\ command\ here would be turned into foo.bar.appid-command, not command. It would be useful for some apps that might want to alias commonly used long commands for end users.

[wjt]

Maybe this was discussed at LAS… @ramcq at one point you had suggested that this would be a more general approach that would allow Flatpak apps to export native messaging hosts, where the protocol only allows executing a single command, not a command with arguments?

[ramcq]

I'm saying that foo.bar.appid-long\ command\ here would be turned into foo.bar.appid-command, not command. It would be useful for some apps that might want to alias commonly used long commands for end users.

I don't really agree with the need for Flatpak to get involved in aliasing. Applications which are not sandboxed manage to export the binaries they want with the names they want in /bin or /usr/bin - why is this suddenly not possible because the same commands are in /app? I reviewed the bin dirs of the ~100 Flatpaks installed on my system and there were 2 which might've needed a little adjustment (eg mv foo foo.bin; mv foo-wrapper foo) to export the expected command name.

[ramcq]

Maybe this was discussed at LAS… @ramcq at one point you had suggested that this would be a more general approach that would allow Flatpak apps to export native messaging hosts, where the protocol only allows executing a single command, not a command with arguments?

Indeed! Being able to export one more binary entry point is pre-work for being able to rewrite the native messaging host files to a binary that exists on the host system. See flatpak/xdg-desktop-portal#705 (comment)

[matthiasclasen]

You just can't override commands safely. There would have to be some user intervention for them to opt-in to that.

I'm saying that foo.bar.appid-long\ command\ here would be turned into foo.bar.appid-command, not command. It would be useful for some apps that might want to alias commonly used long commands for end users.

The feature is targeted at native messaging hosts in browsers, where the json file defining them can only list a bare command, not a commandline with arguments. Therefore, the idea is to let flatpaked messaging hosts export a shell script wrapper that runs them with the right arguments.

We should probably enforce reasonable limits on the command names - no spaces, newlines, slashes, not more than 60-80 chars...

[smcv]

The feature is targeted at native messaging hosts in browsers, where the json file defining them can only list a bare command, not a commandline with arguments. Therefore, the idea is to let flatpaked messaging hosts export a shell script wrapper that runs them with the right arguments.

It might be helpful to describe this feature as "exporting more than one executable" rather than "exporting more than one command", to make it more clear that it's a way for a Flatpak app that contains both /app/bin/foo and /app/bin/bar to export them both as entry points.

Use cases:

• Steam could export steamcmd as a separate entry point, in addition to steam.
• LibreOffice could export lowriter, localc and so on as separate entry points, in addition to loffice.
• An app that provides a native messaging host (like a password manager?) could export /app/bin/native-messaging-host as a separate entry point, in addition to its main GUI.

Non-use-cases:

• If we imagine that git was available as a Flatpak app, if I understand correctly this would not be a suitable way to export git add, git commit, and similar subcommands as separate entry points.
• If I understand correctly, this is also not intended as a way for flatpak-builder to export flatpak-builder --run, flatpak-builder --show-deps, flatpak-builder --show-manifest as separate entry points.

[JakobDev]

I'm saying that foo.bar.appid-long\ command\ here would be turned into foo.bar.appid-command, not command. It would be useful for some apps that might want to alias commonly used long commands for end users.

I'm in favour of giving the possibility to export as command instead of foo.bar.appid-command if the User wants this.

[orowith2os]

I'm in favour of giving the possibility to export as command instead of foo.bar.appid-command if the User wants this.

No. This would conflict with the system binaries, and several apps exporting the same command could be messy. It's best just to add the appropriate terminal exports to the PATH.

[doraskayo]

Duplicated by accident?