Flatpak update command complains about environment variables and overwrites its own output

Ask Fedora
,
1

Anyone have any idea why I get this message when updating flatpaks?

I’m told that the flatpak/exports/share directory is not in the search path, and yet when I display those variables, it in the only one with anything set.

In addition, the output from flatpak is a bit knackered, as the message that is emitted is overwritten by the output that lists what was updated. There are actually 2 further lines displayed after - /root/.local/.share which are overwritten by subsequent output. I’m not even sure who writes the “flatpak” app to report a bug against it.

┌─🎩 lurcher ~
├─
└─➜ sudo flatpak update                                                                                                                                                                  ⏱️ 3s 09:15 Thu 05-Feb
Looking for updates…


        ID                  Branch         Op        Remote         Download
 1. [✓] dev.zed.Zed         stable         u         flathub        125.6 MB / 131.7 MB

Updating… ████████████████████ 100%  11.4 MB/s  00:00
Note that '/var/lib/flatpak/exports/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS
environment variables, so applications may not
be able to find it until you set them. The
directories currently searched are:

- /root/.local/share
        ID                  Branch         Op        Remote         Download
 1. [✓] dev.zed.Zed         stable         u         flathub        125.6 MB / 131.7 MB

Updates complete.

┌─🎩 lurcher ~
├─
└─➜ echo $XDG_DATA_HOME                                                                                                                                                                 ⏱️ 17s 10:40 Thu 05-Feb


┌─🎩 lurcher ~
├─
└─➜ echo $XDG_DATA_DIRS                                                                                                                                                                        10:41 Thu 05-Feb
/home/steve/.local/share/flatpak/exports/share /var/lib/flatpak/exports/share /usr/local/share /usr/share /var/lib/snapd/desktop
2

Just did a quick comparison between your environment variables and mine.

My XDG_DATA_HOME is also empty.

My XDG_DATA_DIRS contains the same elements as yours, but mine are colon-separated, while yours are space-separated.

The XDG spec says:

$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be separated with the separator used for $PATH on the platform (typically this is a colon :).

…so that might be implicated here.

3

Aha - I’ll go and try to locate where they are set, as I’ve never manually touched them.

cheers @pg-tips.

S.

1 Like
4

I think /etc/profile.d/flatpak.sh is how the Flatpak entries get in there.

The relevant line in that script on my system is:

    XDG_DATA_DIRS="${new_dirs:+${new_dirs}:}${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"

where new_dirs has been assigned earlier in the script to have the expected Flatpak locations.

So I wonder if either that profile script has somehow changed, or something else is post-modifying XDG_DATA_DIRS.

5

I believe your problem is that you run the update command with sudo.
Run it without sudo and let flatpak prompt you for a password if necessary.
I have seen the same “warning” if running with sudo.

6

Hmm - good idea. I’ll try this out next time there’s anything to update from flatpak.

7

This did get me looking at how I update my PATH variable, which apparently the fish shell is quite picky about.

It’s not keen on the old set PATH $PATH:some/new/entry/ style and really wants you to use it’s own fish_add_path function. Failure to do this results in some truly bizarre behaviour from the fish_config function.

So, if nothing else, this odd flatpak output has caused me to find and correct some other weirdness in my shell config that’s been there for months, and I’ve never actively noticed until looking into this issue.