Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 178951 - Review Request: environment-modules - Provides dynamic modification of a user's environment
Summary: Review Request: environment-modules - Provides dynamic modification of a user...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ed Hill
QA Contact: David Lawrence
URL: http://www.cora.nwra.com/~orion/fedora/
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-01-25 18:04 UTC by Orion Poplawski
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-14 22:54:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Orion Poplawski 2006-01-25 18:04:51 UTC
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?

Comment 1 Linus Walleij 2006-01-25 19:08:58 UTC
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.

Comment 2 Ed Hill 2006-01-28 03:38:24 UTC
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!



Comment 3 Orion Poplawski 2006-02-02 16:53:45 UTC
(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

Comment 4 Orion Poplawski 2006-02-03 21:17:41 UTC
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.

Comment 5 Ed Hill 2006-02-04 16:36:32 UTC
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.

Comment 6 Orion Poplawski 2006-02-09 18:26:44 UTC
Updated version:

http://www.cora.nwra.com/~orion/fedora/modules-3.2.0p1-1.src.rpm


Comment 7 Ed Hill 2006-02-09 18:40:08 UTC
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" ?

Comment 9 Ed Hill 2006-02-09 19:14:18 UTC
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.  :-)

Comment 10 Ed Hill 2006-02-09 20:45:55 UTC
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.

Comment 11 Orion Poplawski 2006-02-14 22:54:07 UTC
- checked in
- added to owners.list
- builds on devel


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