Bug 542745 - Environment module issues + placement of RPM macro
Summary: Environment module issues + placement of RPM macro
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mpich2
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Deji Akingunola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 539090
TreeView+ depends on / blocked
 
Reported: 2009-11-30 17:33 UTC by Susi Lehtola
Modified: 2010-10-27 11:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-27 11:37:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Susi Lehtola 2009-11-30 17:33:04 UTC
There are still a few problems with the environment module:

- The module MUST be placed in /etc/modulefiles, not /usr/share/Modules/modulefiles.

- MPI_PYTHON_SITEARCH MUST be defined as %{_python_sitearch}/mpich2/.


Also, the RPM macro belongs to mpich2-devel, not mpich2, as you only need it for rpm development.

Comment 1 Susi Lehtola 2009-11-30 17:44:28 UTC
Additionally, you also need to prepend LD_LIBRARY_PATH with %{_libdir}/mpich2/lib in the module to make the libraries visible.

Comment 2 Deji Akingunola 2009-11-30 18:46:30 UTC
(In reply to comment #0)
> There are still a few problems with the environment module:
> 
> - The module MUST be placed in /etc/modulefiles, not
> /usr/share/Modules/modulefiles.
> 
Why is it a 'MUST'? environment-modules manpage doesn't support that assertion, at best the requirement to place it in /etc/modulefiles should be optional.

> - MPI_PYTHON_SITEARCH MUST be defined as %{_python_sitearch}/mpich2/.
> 
Why is that env variable even necessary at all, neither mpich2 nor openmpi install anything under %{_python_sitearch}/, I would rather remove it from mpich2 module file.

Although I've thought of putting some mpich2 python scripts under %{_python_sitelib}, but upstream doesn't intend them to be used that way. Even if I manage to put the *.py under %{_python_sitelib}, the env var. is still not needed in the module file for mpich2.

> 
> Also, the RPM macro belongs to mpich2-devel, not mpich2, as you only need it
> for rpm development.  

Will move around in future update.

Comment 3 Susi Lehtola 2009-11-30 19:26:52 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > There are still a few problems with the environment module:
> > 
> > - The module MUST be placed in /etc/modulefiles, not
> > /usr/share/Modules/modulefiles.
> > 
> Why is it a 'MUST'? environment-modules manpage doesn't support that assertion,
> at best the requirement to place it in /etc/modulefiles should be optional.

Have a look at the Environment Modules guidelines. I should have written it as a MUST.

Anyway, the reason is simple enough to see with

$ module avail
------------------------ /usr/share/Modules/modulefiles ------------------------
dot           module-info   mpich2-x86_64 use.own
module-cvs    modules       null

------------------------------- /etc/modulefiles -------------------------------
openmpi-x86_64


If you put it in /etc/modulefiles, it's a lot easier to see what program modules are available. The stuff in /usr/share/Modules/modulefiles are shell macros.

> > - MPI_PYTHON_SITEARCH MUST be defined as %{_python_sitearch}/mpich2/.
> > 
> Why is that env variable even necessary at all, neither mpich2 nor openmpi
> install anything under %{_python_sitearch}/, I would rather remove it from
> mpich2 module file.

Oh, but there are Python wrappers for MPI such as pypar, mpi4py and so on that are compiled against MPI libraries and need a place to put the files. Then, if there is some Python package that uses those, you would again need the directories.

It's a lot simpler to have those few extra lines in the MPI runtime package spec, than replicate them in other places.

> Although I've thought of putting some mpich2 python scripts under
> %{_python_sitelib}, but upstream doesn't intend them to be used that way. Even
> if I manage to put the *.py under %{_python_sitelib}, the env var. is still not
> needed in the module file for mpich2.

Those can stay in %{_bindir}.

> > Also, the RPM macro belongs to mpich2-devel, not mpich2, as you only need it
> > for rpm development.  
> 
> Will move around in future update.  

Thanks.

***

Furthermore, the Fortran module directory also needs to be fixed, it should be
 MPI_FORTRAN_MOD_DIR %{_fmoddir}/mpich2/
with the mpich2 package owning the directory. We want to follow the filesystem hierarchy standards as closely as possible.

Comment 4 Susi Lehtola 2009-12-17 08:20:52 UTC
ping?

Comment 5 Susi Lehtola 2010-01-26 22:04:56 UTC
ping again! No action in two months?

This needs to be resolved ASAP!

Comment 6 Susi Lehtola 2010-02-08 07:35:17 UTC
ping.

Comment 7 Bug Zapper 2010-03-15 13:23:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Susi Lehtola 2010-03-23 09:53:00 UTC
Okay, so now the value of MPI_PYTHON_SITEARCH is correct.

Could you still move the module file to /etc/modulefiles/ as per the Environment Modules guideline, and add
 prepend-path PYTHONPATH (mpich2 python dir)
to point to the same directory as MPI_PYTHON_SITEARCH? This makes the MPICH2 python modules visible.

**

Btw the setting of MANPATH to /usr/share/man/mpich2 prevents reading man pages in /usr/share/man; that should probably be added to the path, too.. As well as /usr/local/share/man, which is also normally in the default path.

Comment 9 Deji Akingunola 2010-03-23 13:09:58 UTC
(In reply to comment #8)

> 
> Btw the setting of MANPATH to /usr/share/man/mpich2 prevents reading man pages
> in /usr/share/man; that should probably be added to the path, too.. As well as
> /usr/local/share/man, which is also normally in the default path.    

You need to update to environment-modules-3.2.7b-7.{fc11,fc12} currently in updates-testing. And yes, the mpich2 update should have been pushed to stable at the same as the environment-modules one, but ...

Comment 10 Susi Lehtola 2010-10-27 11:37:57 UTC
I guess this is fixed now.


Note You need to log in before you can comment on or make changes to this bug.