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

Bright-Computing / bic

Bright-Illumina collaboration

GNU General Public License v2.0

4 stars 5 forks source link

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

Closed fgeorgatos closed 8 years ago

fgeorgatos commented 8 years ago

""" 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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)