Spec Name or Url: http://www.cora.nwra.com/~orion/fedora/modules.spec SRPM Name or Url: http://www.cora.nwra.com/~orion/fedora/modules-3.2.0-1.src.rpm Description: The Environment Modules package provides for the dynamic modification of a user's environment via modulefiles. Each modulefile contains the information needed to configure the shell for an application. Once the Modules package is initialized, the environment can be modified on a per-module basis using the module command which interprets modulefiles. Typically modulefiles instruct the module command to alter or set shell environment variables such as PATH, MANPATH, etc. modulefiles may be shared by many users on a system and users may have their own collection to supplement or replace the shared modulefiles. Modules can be loaded and unloaded dynamically and atomically, in an clean fashion. All popular shells are supported, including bash, ksh, zsh, sh, csh, tcsh, as well as some scripting languages such as perl. Modules are useful in managing different versions of applications. Modules can also be bundled into metamodules that will load an entire suite of different applications. I have the following rpmlint errors that I'd like to ignore: E: modules script-without-shellbang /usr/share/Modules/init/tcsh E: modules script-without-shellbang /usr/share/Modules/init/bash W: modules hidden-file-or-dir /usr/share/Modules/init/.modulespath E: modules script-without-shellbang /usr/share/Modules/init/.modulespath E: modules script-without-shellbang /usr/share/Modules/init/csh E: modules script-without-shellbang /usr/share/Modules/init/zsh E: modules script-without-shellbang /usr/share/Modules/init/python E: modules script-without-shellbang /usr/share/Modules/init/perl E: modules script-without-shellbang /usr/share/Modules/init/sh E: modules script-without-shellbang /usr/share/Modules/init/ksh Also, I'd be interested in people think /etc/profile.d/ files should be created to initialize the module system by default. I'm tempted to, but my question is that our users use the tcsh, can you have a /etc/profile.d/blah.tcsh and blah.csh with the appropriate one being loaded for each?
It might be proper to mention why modules is popular in its description since few may know about it: When you have several versions of the same software, in a mixed POSIX environment, but still have the same home directory for all these POSIX system, you need to be able to switch between the different versions of the software by altering the system path. Modules solves this. Administrators put in different versions and releases of software at different paths (typically on a fileserver), configures modules with the paths and then let the user switch in and out the different versions and releases for the currently running operating system from the command line.
Hi Orion, I really don't know what to say in regards to the default initialization of modules. Some may view it as helpful while others may think its an annoyance. Since you're packaging it, I think you should get some leeway in deciding whats appropriate. And heres a quick review: good: + source matches upstream + specfile is legible and looks sane + license is correct (GPL) according to the upstream web site but no license is included in the source + builds in mock on FC4 + permissions and dir ownership look OK + code not content nits: - Why the "--disable-versioning" flag? IMHO, its a pretty cool and useful feature. - Please consider naming the package "environment-modules" instead of just "modules" since it is the upstream project name (the "Environment Modules Project") and its a lot less ambiguous. The name "modules" gets used for all sorts of stuff including kernel modules and perhaps a more descriptive name can help avoid some confusion for new users? Its just a suggestion, though. - rpmlint reports: E: modules script-without-shellbang /usr/share/Modules/init/tcsh E: modules script-without-shellbang /usr/share/Modules/init/bash W: modules hidden-file-or-dir /usr/share/Modules/init/.modulespath E: modules script-without-shellbang /usr/share/Modules/init/.modulespath E: modules script-without-shellbang /usr/share/Modules/init/csh E: modules script-without-shellbang /usr/share/Modules/init/zsh E: modules script-without-shellbang /usr/share/Modules/init/python E: modules script-without-shellbang /usr/share/Modules/init/perl E: modules script-without-shellbang /usr/share/Modules/init/sh E: modules script-without-shellbang /usr/share/Modules/init/ksh but I agree that these can probably be safely ignored - Please consider either adding the paper: http://modules.sourceforge.net/docs/MC2_whitney_paper.pdf to the documentation or adding a brief REAME-style link to the homepage and the paper since its very helpful and well- written document. Exactly the sort of thing new users should read!
(In reply to comment #2) > Hi Orion, I really don't know what to say in regards to the default > initialization of modules. Some may view it as helpful while others > may think its an annoyance. Since you're packaging it, I think you > should get some leeway in deciding whats appropriate. I'm going with initialization by default. Seems to go with the extras idea - if you install the software you want to use it. > nits: > - Why the "--disable-versioning" flag? IMHO, its a pretty > cool and useful feature. configuring for Modules 3.2.0 2006-01-17 configure: error: You can not have versioning if --exec-prefix is specified must disable with --disable-versioning What is versioning useful for with modules? Note that this is not the standard --enable-versioning configure option stuff (I think). > - Please consider naming the package "environment-modules" > instead of just "modules" since it is the upstream project > name (the "Environment Modules Project") and its a lot less > ambiguous. The name "modules" gets used for all sorts of > stuff including kernel modules and perhaps a more descriptive > name can help avoid some confusion for new users? Its just > a suggestion, though. But "modules" seems to be the accepted shorthand and that is what the tar file is called. > - Please consider either adding the paper: > > http://modules.sourceforge.net/docs/MC2_whitney_paper.pdf > > to the documentation or adding a brief REAME-style link to > the homepage and the paper since its very helpful and well- > written document. Exactly the sort of thing new users should > read! > I'd rather keep the package size down. It's on the project home page. http://www.cora.nwra.com/~orion/fedora/modules-3.2.0-2.src.rpm
Okay, so it looks like "modules" is obsoleted by module-init-tools, so I've changed the name to environment-modules. Looks like upstream is missing a copy of the GPL with the tarball, so I'm sending a message about fixing that.
OK, thats cool. And I'd like to withdraw my request for the inclusion of the paper (last part of comment #3) because its not released under any clear license/copyright plus its content not code. So the only thing thats going to be changed is the package name, right? If so, just point me towards a new SRPM and I'll take a quick (hopefully last!) look.
Updated version: http://www.cora.nwra.com/~orion/fedora/modules-3.2.0p1-1.src.rpm
I'm getting a 404 from the URL in comment #6 above. Also, I thought that (per comment #4) the package name was going to change from "modules" to "environment-modules" ?
Whoops: http://www.cora.nwra.com/~orion/fedora/environment-modules-3.2.0p1-1.src.rppm
Not to be excessively picky, but the above URL should be "s/rppm/rpm/" and it took me a few minutes to see why I was still getting 404s. :-)
Hi Orion, it appears that you've addressed all the comments, the latest SRPM just built cleanly for me in mock (FC4 i386), and I don't see any remaining blockers. APPROVED.
- checked in - added to owners.list - builds on devel