Add the ability to make 'extra-args' as passed to `flatpak run` permanent

[erindru]

Linux distribution and version

Fedora 30

Flatpak version

1.2.4

Description of the problem

flatpak run allows you to pass extra arguments to the command specified within the manifest. However, flatpak override does not provide a means to make these permanent, despite the confusing documentation on the manpage.

The manpage states:

But the user can override it on a particular instance by specifying extra arguments to flatpak run, or every time by using flatpak override.

Unless I am missing something, flatpak override cannot permanently override everything that is overridable by flatpak run, namely the --command and the extra args.

In my use case, I am using the DBeaver Community flatpak and I want to pass some extra arguments to it that are specific to my environment, such as -vmargs -Djava.security.krb5.debug=true -Djava.security.krb5.realm=<my kerberos realm> -Djava.security.krb5.kdc=<my kdc>.

This works great with flatpak run, however I cannot see a way to make it permanent with flatpak override.

Has the ability to override the extra-args been implemented?

[matthiasclasen]

What the man page refers to are the options that override and run share, such as --filesystem= or --talk-name=

There is no mechanism to permanently store extra commandline arguments.

Why not just make a shell script that does what you need ?

[erindru]

Well, I don't need a shell script to make other things permanent (such as adding environment variables) - is this different?

One thing I didn't mention is that I launch this application from the GNOME launcher via its icon. I'd like my changes to take effect without having to modify the .application file to execute an arbitrary script instead and having my modifications blown away on upgrades

[matthiasclasen]

Its different.

The options that override persists are flatpak options, not application-specific things that we don't know how to parse or handle.

[erindru]

That isn't true - the overrides (at least that I have used so far) have absolutely been application-specific.

For example, I use the Steam flatpak and needed to add a filesystem override so that Steam could see my games folder on a different hard disk. I also added an override to set the JAVA_HOME environment variable in the Visual Studio Code flatpak so that it could find the correct Java compiler. No other application on my system needs these particular overrides (unless you were saying that the concept of environment variables and volume mounts are not application specific - which I would agree, and add that the concept of application arguments is also not application specific).

What I was expecting to find was something similar to how docker-compose allows you to define overrides for all the options in docker run (if you're familiar with Docker) - including the application binary (called entrypoint in docker-compose land) and any arguments passed to it (called command in docker-compose land).

So there is two things here:

1. The ability to override the flatpak command - you do know how to deal with this value because you already do in the application manifest, its command in the [Application] section
2. The ability to override the extra_args - this is just a random user-supplied string. How does flatpak run handle this currently? You'd basically just store this string somewhere in the overrides file and insert it after the command every time the flatpak is invoked, in the same way that flatpak run does

Unfortunately flatpak is written in C so my ability to contribute something sane to the codebase is limited

[Arxcis]

Bump :+1:

My use-case

• Chrome v87 just came out with the long-awaited Ozone windowing-backend with support for Wayland.
• To enable this new feature I would have to run Chrome like this:

flatpak run com.google.Chrome --enable-features=UseOzonePlatform --ozone-platform=wayland

• I would like to make this a permanent override.
• Here is how I would like the overrides-file to look like:

Overrides-file: ~/.local/share/flatpak/overrides/com.google.Chrome

[Application] 
command=chrome --enable-features=UseOzonePlatform --ozone-platform=wayland

[Context]
sockets=!x11

Default metadata for reference: ~/.local/share/flatpak/app/com.google.Chrome/current/active/metadata

[Application]
name=com.google.Chrome
runtime=org.freedesktop.Platform/x86_64/20.08
sdk=org.freedesktop.Sdk/x86_64/20.08
tags=proprietary;
command=chrome
required-flatpak=1.8.2

[Context]
shared=network;ipc;
sockets=x11;wayland;pulseaudio;cups;
devices=all;
filesystems=host-etc;xdg-documents;xdg-music;xdg-download;xdg-videos;

// ...and more

[Arxcis]

Bonus Adding support for the command-argument in the override files, would enable GUI tools like Flatseal to add arguments to applications, in a platform-independent way.

[Erick555]

@Arxcis what you are looking for is ~/.var/app/com.google.Chrome/config/chrome-flags.conf not flatpak overrides.

[Arxcis]

@Erick555 Thanks! That solved my problem :+1:

I still would enjoy this feature though, since every app may have a different way of persisting args. If I have 20 apps, I have to remember the 20 different ways of persisting args. Even chrome and chromium have different files for this: config/chrome-flags.conf vs config/chromium-flags.conf. Flatpak has the potential to present a unified interface adding extra-args.

Having said that. My problem is solved. Yippi! :smile:

[lukekendall]

Perhaps a better use case is where the flatpak provides an IDE, with commands like compilers that you'd like to be able to run from the command line, with varying arguments. A case in point would be the gnome-inform7 IDE, where it would be good to have access to the compiler components (ni, cBlorb, inform6). You can run them via, e.g., flatpak run --command="/app/libexec/gnome-inform7/ni" com.inform7.IDE, but you can't then pass any arguments to the compiler, so the --command option becomes basically useless. The only solution would be to write a shell script that took the arguments you wanted, then that script wrote a shell script to run the compiler with those arguments... That's ugly. Or is there some better way to handle this use case?

[17steen]

this would be useful for allowing vs-code to run in wayland, which it now can but needs those flags to be provided

[Arxcis]

Same goes for Signal over Wayland - see WIP here https://github.com/signalapp/Signal-Desktop/issues/3411.

It is the same issue for any Electron-v12-based app, because Electron v12 introduced opt-in Wayland support, exposing the chromium-flags mentioned above:

--enable-features=UseOzonePlatform --ozone-platform=wayland

[nanonyme]

This idea of overriding command permanently seems like a quick trip to maintenance mess. Many apps have entrypoint scripts and these may even (in case of com.valvesoftware.Steam) do data migrations on startup. Making command first-trade overridable seems like a route to misery for application maintainers who get esoteric bug reports when users have picked up overrides from a third-party wiki and started bypassing the tested codepaths. Adding extra flags to command invocation on the other hand seems mostly harmless.

[lukekendall]

My request was not for the purpose of overriding options that would make the commands misbehave (which would be the same case as choosing options that made a natively compiled version of the program fail, too), but to pass in additional reasonable parameters, as in the example I gave.

[JKAnderson409]

For anyone still struggling with this, I found a workaround that I use on Gnome 40. It should work on KDE and most other environments because it is based on a Free Desktop spec.

This example launches VSCodium (installed with Flatpak) with Wayland support. Create the file ~/.local/share/applications/codium-custom.desktop with this content:

[Desktop Entry]
Name=VSCodium (Wayland)
Comment=Code Editing. Redefined.
GenericName=Text Editor
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/codium --file-forwarding com.vscodium.codium --no-sandbox --unity-launch --enable-features=UseOzonePlatform --ozone-platform=wayland @@ %F @@
Type=Application
Icon=com.vscodium.codium
StartupNotify=false
StartupWMClass=Codium
Categories=Utility;TextEditor;Development;IDE;
MimeType=text/plain;inode/directory;application/x-code-workspace;
Actions=new-empty-window;
Keywords=vscodium-custom;

[Desktop Action new-empty-window]
Name=New Empty Window
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/codium --file-forwarding com.vscodium.codium --no-sandbox --new-window --enable-features=UseOzonePlatform --ozone-platform=wayland @@ %F @@
Icon=com.vscodium.codium

This is a cool Free Desktop feature that I never knew about until I faced this issue. The use cases described by @Arxcis and @erindru should be easy enough to cover with this technique. Unlike Chromium, VSCodium does not have a place to customize how Flatpak launches it by default (at least not that I could find).

I found the default .desktop file for the VSCodium Flatpak in /var/lib/flatpak/exports/share/applications/ but I decided to leave it alone and make a new one for Wayland. I just added the arguments for Wayland to the "Exec" key and gave it a name that differentiates it from the original. The spec, along with the default .desktop for the app, should provide everything you need to make this work for whatever your use case may be.

I was initially in agreement that Flatpak needed some way to change the behavior of flatpak run for each program. Now that I know about this, I actually prefer it to a feature that adds extra arguments to flatpak run. The command line options can remain clean and predictable while we use a Free Desktop solution to launch the app in the different way. This is the GUI equivalent of an alias on the command line.

[R0flcopt3r]

I am not sure if this works specifically for flatpak software, but it does work for desktop files in /usr/share/applications/.

If you name the file in .local/share/applications the same as the one in flatpak it should "overwrite" it, meaning it will only show the one in .local/share/applications.

example:

~/.local/share/applications/some_program.desktop
/var/lib/flatpak/exports/share/applications/some_program.desktop

This is independent from the actual contents of the .desktop file. That way you don't need to have different names, and as only "your" version will show up.

[JKAnderson409]

That's a good tip, I renamed it to com.vscodium.codium.desktop and my custom VSCodium launcher is now the only one. I also tried replacing the Gnome Terminal launcher with one that launches kitty, neither of which are installed with Flatpak, and it works the same way.

[Arxcis]

Thank you very much @JKAnderson409 for a very good workaround :+1:

So in summary what I ended up doing was following @JKAnderson409 's advice and did this:

cp ~/.local/share/flatpak/exports/share/applications/org.signal.Signal.desktop \
   ~/.local/share/applications/

# Edit copy to my liking without modifying the original.
vim ~/.local/share/applications/org.signal.Signal.desktop 

My custom ~/.local/share/applications/org.signal.Signal.desktop now looks like this:

[Desktop Entry]
Name=Signal
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=signal --file-forwarding org.signal.Signal --enable-features=UseOzonePlatform --ozone-platform=wayland  @@u %U @@

# ...more stuff below this line, which I did not modify

[BeatLink]

Are there any updates on this?

[Erick555]

If you read answers from actual developers you may conclude implementing this is unlikely to happen. You may edit desktop file or make a shell script the same way you do for non-flatpak apps.

[BeatLink]

How is that a better way of managing command overrides than building functionality into flatpak?

[Erick555]

It was explained before this functionality may be too complicated to implement. It also doesn't exist outside flatpak so it's nice but not crucial feature.

[ardasevinc]

I wrote a blog post about this issue while collecting tips here. Thanks to @Arxcis and other awesome people here!

https://ardasevinc.dev/launch-flatpak-apps-with-custom-args-and-environment-variables

[kon14]

Remove the --user flag if your application is installed system-wide.

@ardasevinc Somewhat of a nitpick, but user/system override flags are not related to user/system/custom app installation paths. You can set a --user level override (for your user) on a system-installed Flatpak and vice versa.

[ardasevinc]

Remove the --user flag if your application is installed system-wide.

@ardasevinc Somewhat of a nitpick, but user/system override flags are not related to user/system/custom app installation paths. You can set a --user level override (for your user) on a system-installed Flatpak and vice versa.

Thank you! I didn't know that, will make the necessary changes

[muelli]

My usecase is only mildly related, but let me mention it regardless: For reasons I am not proud of I need to run proprietary software that is quite memory hungry and likes to stall the rest of my system, eventually kicking off the OOM killer slaying random apps. I would like to run certain flatpaks with nice, ionice, and choom.

[TheNexter]

This feature could be soooo good to have, some apps require some flags to be used normally like with 4K screen. DrawIO require the flags --zoom 1.5 to have a good scale, please implement this feature.

Without :

With :

[Termuellinator]

Crazy that this is still not an option :/ Modifying the desktop file after every update is as annoying as having to check if anything relevant changed in the updated desktop file. Voting to have this implemented ;)

[hfiguiere]

DrawIO require the flags --zoom 1.5 to have a good scale, please implement this feature.

How about fixing drawio?

[apathoid]

It was explained before this functionality may be too complicated to implement.

Can you explain why it may be complicated, please? If I understand it correctly, all that is needed is to collect command line arguments provided by a user and pass them (as is) to the command.

If the parsing of a set of independent arguments is difficult (though I think it is possible, because every argument has a unique name), then the user could be allowed to specify all the arguments as a single string (better than nothing, I think).