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
