bug#48398: many packages become nonfunctional if not install in fixed profile like ~/.guix-profile

[Shyam Saran]

This below error I am getting

$ blueman-manager                                                                                                                                                                                                              718s

blueman-manager version 2.1.4 starting
Traceback (most recent call last):
  File "/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-2.1.4/lib/python3.8/site-packages/blueman/main/Manager.py", line 111, in on_dbus_name_appeared
    check_bluetooth_status(_("Bluetooth needs to be turned on for the device manager to function"),
  File "/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-2.1.4/lib/python3.8/site-packages/blueman/Functions.py", line 73, in check_bluetooth_status
    if "PowerManager" not in applet.QueryPlugins():
  File "/gnu/store/qrpkvnya5z5q2n1lc024wbxb27p9wrzq-python-pygobject-3.34.0/lib/python3.8/site-packages/gi/overrides/Gio.py", line 351, in __call__
    result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Applet was not provided by any .service files (2)

(thanks for support)

On Fri, 14 May 2021 at 03:25, Leo Prikler <leo.prikler@student.tugraz.at> wrote:

Am Donnerstag, den 13.05.2021, 19:56 +0530 schrieb Shyam Saran:
> many packages become nonfunctional if not install in fixed profiles
> (e.g. ~/.guix-profile)
While this is true, there is not necessarily a common cause for all
such instances.  Even among packages, that hardcode ~/.guix-profile,
there might be differences, so it's better to focus on specific
instances or groups of instances, in which one fix can be applied to
all of them.

> 1. blueman
Please provide more information on blueman.
> 2. font-conf so most of font like font-lohit will not be available
This one has a history.  Instead of exposing itself to the dangers of
environment variables, fontconfig took the reasonable approach of
letting itself be controlled by XML files, so if you want it to work
differently from how it usually behaves, you have to edit those.

> I had noticed that fixed profiles have become part of many
> packages/services definition which could be the reason that many of
> these packages/services become dependent on these fixed profiles.
Which packages/services in particular?

> It can be checked with
>
> $ ag   --scheme  '.guix-profile'
> $ grep -r '.guix-profile'
>
> in code
I find 65 matches including documentation.  Even assuming every one of
them was a package, it would affect about 1% of packages, many of which
would probably be leaf packages.  So while this number is definitely
large enough to intimidate those who want to quickly fix a number of
them, it is also smaller in scale than the report would imply.

>
> Also
>
> We provides necessary services through putting environment variables
> in each profiles
>
> PROFILE_PATH/etc/profile
>
>   like for pidgin/purple
>   PURPLE_PLUGIN_PATH
>
>   for libraries
>   LIBRARY_PATH
>
>
> As suggestion
>
> We could first provide augment all variables with guix specific
> prefix e.g. GUIX_PEV_...
> (PVS profile environment variables.)
>
> So these all variables will become
>
>
>   GUIX_PEV_PURPLE_PLUGIN_PATH
>   GUIX_PEV_LIBRARY_PATH
>
> then we could or could not (left to user) to set them
>   PURPLE_PLUGIN_PATH=$GUIX_PEV_PURPLE_PLUGIN_PATH
>   LIBRARY_PATH=$GUIX_PEV_LIBRARY_PATH
>
>
> So with prefixed env vars, in first look one will know it is coming
> from guix related profiles.
> maybe it will also help in removing dependencies on fixed profiles.
Guix already prefixes some environment variables, that might cause
issues if they are read by all variants of a package with GUIX_.  I
don't think this needs to be done for every search path, however.
Again, specific instances like GUIX_PYTHONPATH can (and should be)
discussed, but I don't think this solves the relation to fixed
profiles.

Regards,
Leo