-
-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to make 'extra-args' as passed to flatpak run
permanent
#2913
Comments
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 ? |
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 |
Its different. The options that override persists are flatpak options, not application-specific things that we don't know how to parse or handle. |
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 So there is two things here:
Unfortunately flatpak is written in C so my ability to contribute something sane to the codebase is limited |
Bump 👍 My use-case
Overrides-file: ~/.local/share/flatpak/overrides/com.google.Chrome
Default metadata for reference: ~/.local/share/flatpak/app/com.google.Chrome/current/active/metadata
|
Bonus |
@Arxcis what you are looking for is |
@Erick555 Thanks! That solved my problem 👍 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: Having said that. My problem is solved. Yippi! 😄 |
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. |
this would be useful for allowing vs-code to run in wayland, which it now can but needs those flags to be provided |
Same goes for Signal over Wayland - see WIP here signalapp/Signal-Desktop#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:
|
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. |
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. |
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
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 I was initially in agreement that Flatpak needed some way to change the behavior of |
I am not sure if this works specifically for flatpak software, but it does work for desktop files in If you name the file in example:
This is independent from the actual contents of the |
That's a good tip, I renamed it to |
Thank you very much @JKAnderson409 for a very good workaround 👍 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 [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 |
Are there any updates on this? |
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. |
How is that a better way of managing command overrides than building functionality into flatpak? |
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. |
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 |
@ardasevinc Somewhat of a nitpick, but user/system override flags are not related to user/system/custom app installation paths. |
Thank you! I didn't know that, will make the necessary changes |
My usecase is only mildly related, but let me mention it regardless: |
Crazy that this is still not an option :/ |
How about fixing drawio? |
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). |
Linux distribution and version
Fedora 30
Flatpak version
1.2.4
Description of the problem
flatpak run
allows you to pass extra arguments to thecommand
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:
Unless I am missing something,
flatpak override
cannot permanently override everything that is overridable byflatpak 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 withflatpak override
.Has the ability to override the
extra-args
been implemented?The text was updated successfully, but these errors were encountered: