MODULEPATH definitions under /etc/profile.d must be w. guarded variable

[fgeorgatos]

"""
Verify that MODULEPATH definitions under /etc/profile.d are always w. guarded variable for either Lmod/Tmod ## reported bug #10582, handled on 13/11/2015
"""

I believe this was fixed as of Bright v.7.0-44; is it the case that all of 7.x variants have the bugfix?

Of special interest is the Bright/7.0 against Centos6 case, see #9

[fgeorgatos]

as of 31/3/2016:

• Tmod is handled with 7.0-92 patches and onwards, since some guarding logic has been added
• Lmod/6.0, as it comes from EPEL repo, is not proper because it has hardwired MODULEPATH :-(

[fgeorgatos]

Wow, one extra group of people introducing the exact same bug we started with:
https://github.com/openhpc/ohpc/blob/issue_178/components/admin/lmod/SPECS/lmod.spec

a hardwired $MODULEPATH breaks module use across inherited shells, please avoid that!

[boegel]

@fgeorgatos is that still the case with recent Lmod versions? I think these pick up an existing $MODULEPATH without too much trouble?

Can you explain what problems you run into exactly, and share error messages, etc?

[fgeorgatos]

@boegel: sry, I only now see your message; as discussed over easybuild update calls, the following was broken across several - really many- environment modules implementations (mostly at packaging level providing for /etc/profile.d scripts):

echo $MODULEPATH
mkdir $HOME/privatemodules
module use $HOME/privatemodules
echo $MODULEPATH
bash
echo $MODULEPATH

As of commit 1e9ba21 in this branch, this issue should no longer exist for Lmod, nor for Tmod as it comes from Bright (non-blocking improvements expected on either .spec file, though)

Fedora picked up on the bug last week and got it fixed for Lmod, too:
https://bugzilla.redhat.com/show_bug.cgi?id=1326075
https://bodhi.fedoraproject.org/updates/Lmod-6.3.1-3.el6
I highly recommend to look at that as a reference implementation for many others (plz verify this)

[fgeorgatos]

this is guarded now sufficiently, as regards generic Lmod/Tmod deployments, so resolving
(a little internal issue #12041 is considered related but not a blocker)