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(a)fedoraproject.org