Re: Draft for the use of environment-modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2009-07-24 at 10:43 -0400, Doug Ledford wrote:
> > I'm not quite sure if MPI software spec files, too, should be 3rd  
> > party
> > compiler compatible as the MPI compiler spec files.
> 
> With properly functioning MPI installations, there are only very minor  
> differences for 3rd party specs.  They could build all mpi versions in  
> one go from a single src rpm, or they could have very slightly  
> different src rpms, one for each mpi.  If they opt to build all of  
> them in one go, they could do something like this:

clip

AFAIK you must do off-root builds in %build and install in %install to
conform to the RPM standard. The spec file template in the MPI draft
does this.


> > That's a valid option, but makes updating the MPI compiler impossible
> > since at least currently with openmpi the dirs are versioned:
> >
> > setenv                  MPI_BIN         /usr/lib/openmpi/1.3.3-gcc/bin
> > setenv                  MPI_LIB         /usr/lib/openmpi/1.3.3-gcc/lib
> > setenv                  MPI_HOME        /usr/lib/openmpi/1.3.3-gcc
> 
> lam is already non-versioned, and as of openmpi-1.3.2, they expect  
> version upgrades to no longer be binary incompatible, so I intend to  
> unversion it as well.  At a minimum we could always leave the current  
> version unversioned and just make it so that if someone wants to  
> install an older version, then they need to put the version back.

Those directories are meant only for packaged software. I think less
directories is better, especially if you might end up with unowned
directories as in the versioned case.

Thus you shouldn't have to care about possible incompatibities: if the
compiler is upgraded the software has to be rebuilt.

So, it is good to have a versioned MPI directory. Maybe we need
versioned Requires: on the MPI runtime in MPI enabled software to cope
with the directory problem?

> >> 2) Try to split things up into normal FHS locations, but don't use
> >> binary name suffixes or library name suffixes in the normal
> >> directories, instead use things like /bin/%{name}-%{_arch}%{?
> >> opt_cc_suffix}, %{_libdir}/%{name}%{?opt_cc_suffix}, %{_includedir}/%
> >> {name}-%{_arch}%{?opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{?
> >> opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{?opt_cc_suffix}/man.
> >> While the above is somewhat clumsy, and also eliminates the
> >> possibility of MPI_HOME being useful as we would now need independent
> >> definitions of all the various MPI locations, it does have the  
> >> benefit
> >> of being mostly FHS compliant.
> >
> > OK, this holds for MPI compilers, and the directories can be reused  
> > for
> > other software, but may be a bit messy..
> 
> It is messy, I don't argue that one bit ;-)  But I suspect we are less  
> likely to get yelled at for this than, say, creating /usr/mpi (just  
> think back to how much people complained about /usr/java, and they did  
> away with /usr/X11 entirely, I just expect they would see /usr/mpi as  
> a step in the wrong direction).

The architecture problem in the first option has convinced me that it is
not so simple as it appeared to be at first glance. So I think we end up
with the second option.

> >> Regardless of which way people would prefer to go, I do think we
> >> should go ahead and standardize all the config files in % 
> >> {_sysconfdir}/
> >> %{name}-%{_arch}%{?opt_cc_suffix} so that they won't possibly be on a
> >> read only filesystem.
> >
> > So far I haven't seen any MPI software with a config file in /etc.
> 
> By default, openmpi and lam both have some files they would put in / 
> etc/ if I didn't have their --prefix set to MPI_HOME.  And I got  
> yelled at on f-d for having the etc files in MPI_HOME/etc since  
> someone might want to make local modifications while MPI_HOME might be  
> on a read only network fs mount.

OK, MPI compilers and runtime may have such config files. I was thinking
about software.

> > IMHO if opt_*flags are defined then $RPM_OPT_FLAGS should not be used,
> > since the compiler might support the flags in $RPM_OPT_FLAGS.
> 
> There might be some options that aren't supported by other compilers,  
> but there are a lot of general options in optflags that we would like  
> to preserve.  For alternate compilers, I think it's reasonable to have  
> people use sed to remove unwanted options.

Maybe they just make their own macro to put them in and #define
opt_*flags %{_proprietary_optflags}. Or write the flags explicitly in
the spec file. In either case, I don't think you should use
$RPM_OPT_FLAGS if opt_*flags are defined.

> > Also, you
> > should use %{optflags} instead of $RPM_OPT_FLAGS as you're using
> > %{buildroot} instead of $RPM_BUILD_ROOT.
> 
> But then they can't use sed to filter out the options they don't  
> want ;-)  In order to sed filter the options, they have to be a shell  
> variable not an rpm macro.

Then declare a shell variable in the spec file and initialize it with
%{optflags}. That way you aren't breaking the guidelines :-)
-- 
Jussi Lehtola
Fedora Project Contributor
jussilehtola@xxxxxxxxxxxxxxxxx

--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux