GNU bug report logs - #44997
Flatpaks are invisible to application launchers

Previous Next

Package: guix;

Reported by: guixuser6392 <guixuser6392 <at> protonmail.com>

Date: Tue, 1 Dec 2020 20:34:02 UTC

Severity: normal

To reply to this bug, email your comments to 44997 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: guixuser6392 <guixuser6392 <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: Flatpaks are invisible to application launchers
Date: Tue, 01 Dec 2020 20:33:37 +0000
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):

From: guixuser8421 via web <issues.guix.gnu.org <at> elephly.net>
To: 44997 <at> debbugs.gnu.org
Subject: Flatpaks are invisible to application launchers
Date: Wed, 17 Mar 2021 11:15:17 +0100
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):

From: John Kehayias <john.kehayias <at> protonmail.com>
To: "44997 <at> debbugs.gnu.org" <44997 <at> debbugs.gnu.org>
Subject: Flatpaks are invisible to application launchers
Date: Tue, 17 Aug 2021 03:01:35 +0000
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):

From: Olivier Rojon <o.rojon <at> posteo.net>
To: John Kehayias <john.kehayias <at> protonmail.com>
Cc: "44997 <at> debbugs.gnu.org" <44997 <at> debbugs.gnu.org>
Subject: Re: bug#44997: Flatpaks are invisible to application launchers
Date: Wed, 16 Apr 2025 04:15:18 +0000
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):

From: Danny Milosavljevic <dannym <at> friendly-machines.com>
To: Olivier Rojon <o.rojon <at> posteo.net>
Cc: John Kehayias <john.kehayias <at> protonmail.com>,
 "44997 <at> debbugs.gnu.org" <44997 <at> debbugs.gnu.org>
Subject: Re: bug#44997: Flatpaks are invisible to application launchers
Date: Sun, 18 May 2025 13:36:58 +0200
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):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Danny Milosavljevic <dannym <at> friendly-machines.com>
Cc: John Kehayias <john.kehayias <at> protonmail.com>,
 "44997 <at> debbugs.gnu.org" <44997 <at> debbugs.gnu.org>,
 Olivier Rojon <o.rojon <at> posteo.net>
Subject: Re: bug#44997: Flatpaks are invisible to application launchers
Date: Tue, 20 May 2025 08:27:27 +0900
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.