Summary:

Now that GNOME has switched to using systemd to launch its apps, there is no
longer a reliable way to define system-wide bash functions for people who use GNOME.
One subsystem which needs these is the environment modules system as implemented
by the Lmod package, which is required by several other Fedora packages including
mp and openmpi.  The third-party package Anaconda also works by defining bash
functions.  These now no longer work under some conditions when a user logs in
to a GNOME session on Fedora 32, but they work in other desktop environments
and they used to work in GNOME sessions on Fedora 30.

Background:

Environment modules provide the user with a way to dynamically change the
environment by means of module files typically supplied by other packages.
For example, the module file provided with openmpi extends PATH, LD_LIBRARY_PATH
and PKG_CONFIG_PATH to include the paths used by openmpi and sets several MPI_
environment variables.  It is done this way because you might also have
installed mpich which implements the same featureset and this makes it possible
to choose between the implementations at run time.  (Similarly, Anaconda is
an implementation of Python, and it is useful to give the user a method to
switch between Anaconda and the system Python installation at run time.)

In order to select openmpi, you type into your shell:
module load mpi/openmpi-x86_64

Because this has to affect the environment of the running shell, the "module"
command must be implemented as a shell function.  In bash, the most common
shell, this is done by putting the function definition in /etc/profile.d and
letting it be defined at login.  It is then exported with the bash command
"export -f" so that other shells that you start during this session will also
inherit this function definition.

Issue:

If you log in to a user account with no ~/.bashrc and select GNOME desktop on
Fedora 32 then type "module load mpi/openmpi-x86_64" you will get "module:
command not found".  This is a regression from Fedora 30, where it worked
properly, and it is also not an issue in most other desktop environments
where systemd is not used to launch the apps.

The way bash exports functions is by setting an environment variable called
"BASH_FUNC_functionname%%" and these variables are being stripped out of the
environment by systemd, whereas with the traditional way of starting a desktop
the environment variables - and thus the bash functions - are simply inherited
by the child processes of the desktop session manager.

My guess is that the variables are being stripped because they are not
POSIX compliant (and necessarily have to be that way because of
Shellshock/Bashdoor).

Unfortunately, bash does not offer any other foolproof way of defining
system-wide functions, because interactive non-login shells (such as would
appear in any terminals opened inside a GNOME session) do not read any
system-wide initialisation files - unlike login bash shells which read in
/etc/profile (and unlike zsh which reads in /etc/zshrc).

As it happens, there *is* an /etc/bashrc which sources /etc/profile.d/*.sh -
but bash doesn't read in this file unless your ~/.bashrc tells it to.  Maybe
most bash users have this in their ~./bashrc?  Certainly users who have
inherited their .bashrc from /etc/skel do.

So the question is: should systemd allow environment variables ending with '%%'
to be exported, or is it enough to require users to source /etc/bashrc in
their ~/.bashrc and tell them it's their own fault if they don't?  (Why doesn't
bash do this itself if it's required?)

See also:

https://github.com/systemd/systemd/issues/14878
Bug 1754395