GNU bug report logs -
#44997
Flatpaks are invisible to application launchers
Previous Next
To reply to this bug, email your comments to 44997 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#44997
; Package
guix
.
(Tue, 01 Dec 2020 20:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
guixuser6392 <guixuser6392 <at> protonmail.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 01 Dec 2020 20:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Applications installed by Flatpak can't be discovered by application launchers. A fix to this is to add the directories '/var/lib/flatpak/exports/share' and '$HOME/.local/share/flatpak/exports/share' to the search path set by the XDG_DATA_DIRS environment variable.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#44997
; Package
guix
.
(Wed, 17 Mar 2021 10:16:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 44997 <at> debbugs.gnu.org (full text, mbox):
Flatpak does export /etc/profile.d/flatpak.sh, that should set up XDG_DATA_DIRS. But I don't think there's a canonical way of using it in guix. Another way is to modify the package to do exactly what you said.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#44997
; Package
guix
.
(Tue, 17 Aug 2021 03:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44997 <at> debbugs.gnu.org (full text, mbox):
I agree this should be exported by the flatpak package. I haven't hit any other packages putting anything in /etc/profile.d, though that does happen I know (so perhaps Guix should incorporate or patch such things?). Flatpak is also due for an update soon I think, so that would be a good time to make the modification perhaps.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#44997
; Package
guix
.
(Wed, 16 Apr 2025 04:16:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 44997 <at> debbugs.gnu.org (full text, mbox):
Hej,
I understand it has been some time since this issue has been opened and I suppose that in
the meantime, the mentioned Flatpak update has already taken place (quite presumptuous, I
know ;-)).
However, on my end, it is still the case that the directories
'/var/lib/flatpak/exports/share' and '/home/hapster/.local/share/flatpak/exports/share'
are not exported which results in them not being shown in applications launchers such as
the one incorporated in the GNOME Shell.
Is it possible there now is a solution that does not incorporate adding search paths to
the package? Because if there isn't, I don't see why the package should not be altered in
order to just export those paths -- it seems like a solution that is much cleaner than me
exporting them in shell init files or in the guix home environment.
Have a good day :)
John Kehayias <john.kehayias <at> protonmail.com> writes:
> I agree this should be exported by the flatpak package. I haven't hit any other packages
> putting anything in /etc/profile.d, though that does happen I know (so perhaps Guix should
> incorporate or patch such things?). Flatpak is also due for an update soon I think, so
> that would be a good time to make the modification perhaps.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#44997
; Package
guix
.
(Sun, 18 May 2025 11:38:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 44997 <at> debbugs.gnu.org (full text, mbox):
Hi,
>Is it possible there now is a solution that does not incorporate adding search paths to the package?
I've just put the following line in ~/.bash_profile (which is generated by guix-home in my case--but it doesn't matter much):
. ~/.guix-home/profile/etc/profile.d/flatpak.sh
It works fine (in sway on Wayland, using nwggrid). I'm using flatpak quite a bit.
You could also put it in ~/.profile .
>Because if there isn't, I don't see why the package should not be altered in order to just export those paths -- it seems like a solution that is much cleaner than me exporting them in shell init files or in the guix home environment.
I used to think that, but nowadays I prefer when it's me exporting them in a shell init file. The guix home installer could just automatically add the command (see above) to a (managed or not) bash_profile (and some disgruntled users can remove it again ;) ).
Also, if we would set native-search-paths in a guix package, we could only set it to refer to some file within a guix package. And ${HOME}/.local/share/flatpak is not within any guix package.
We could do it in a profile hook--but that would mean we'd have to have a flatpak profile hook and guix would ALWAYS have to check flatpak--even if the user doesn't use flatpak. It would be possible--but I don't think we want to have a hard-coded dependency on flatpak in all cases.
Also, auto-exporting XDG_DATA_DIRS would take control from the user (which order should the XDG_DATA_DIRS environment variable be amended in--and thus which package source should be preferred?).
In summary, we are trying to be modular and this XDG_DATA_DIRS=/home/xx/random_directory is NOT modular. flatpak needs it for its own stuff--but it doesn't have an activate script. The flatpak.sh is the closest thing, kinda like a venv activate script. Why not use it?
That said, I haven't used GNOME in a very long time. For all I know they could not load ~/.bash_profile in the first place or something... (that would be dumb)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#44997
; Package
guix
.
(Mon, 19 May 2025 23:28:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44997 <at> debbugs.gnu.org (full text, mbox):
Hi,
Danny Milosavljevic <dannym <at> friendly-machines.com> writes:
> Hi,
>
>>Is it possible there now is a solution that does not incorporate adding search paths to the package?
>
> I've just put the following line in ~/.bash_profile (which is
> generated by guix-home in my case--but it doesn't matter much):
>
> . ~/.guix-home/profile/etc/profile.d/flatpak.sh
I think the new etc-bashrc-d-service-type proposed in bug#78308 could be
used for that, if you'd like to try it out/review it.
--
Thanks,
Maxim
This bug report was last modified 29 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.