On Wed, 2009-01-07 at 09:20 -0800, Toshio Kuratomi wrote:
> Doug Ledford wrote:
> > On Tue, 2009-01-06 at 14:37 -0800, Toshio Kuratomi wrote:
> >> Doug Ledford wrote:
> >>> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
> >>>> * Make adherence to the FHS a MUST, with the added exception of
> >>>> /usr/<target> for cross toolchains.
> >>> I happen to have a few packages that just *can't* follow FHS (unless we
> >>> opt to ignore FHS and allow a package to install to /opt, but that's
> >>> always been just as verbotten by the FHS for the initial software
> >>> distributor versus an ISV as failing to follow any other FHS specified
> >>> layout).
> >>>
> >> Example SRPMS? (Or the package name if it's already in cvs).
> >
> > The main ones are all MPI implementations. They need per arch and per
> > version libraries and runtimes. OpenMPI is in cvs, but hasn't been
> > updated to my current layout as used in RHEL. I tried, for about 5
> > consecutive releases, to adhere to the FHS with that package. It just
> > ended up being more problems than could be solved. The current version
> > of the package as shipped in RHEL (and there is an example of it in the
> > Infiniband link in my sig) puts the entire tree under
> > %{_libdir}/%{name}/%{version}-%{opt_cc}. While you can *attempt* to get
> > OpenMPI to work with a FHS standard layout, the two other main MPIs,
> > mvapich and mvapich2, flat will not work with a FHS layout at all. They
> > *must* be installed under a single directory prefix that doesn't
> > conflict with any other installations.
> >
>
> openmpi doesn't look too bad. If this was being reviewed with the FHS
> Guideline in mind, these are the questions I'd ask:
As mentioned in my original mail, you are looking at the older version
of OpenMPI in Fedora CVS, where as the version on my people.redhat.com
page for RHEL is both A) significantly newer and B) has a vastly
different file layout because the file layout you are seeing in the
Fedora CVS version of the package proved to be impossible to get
completely right.
However, even though you are referencing a layout that proved not to be
effective, I'll address your questions because I think the answers might
point out why it's so hard to get OpenMPI right:
> /usr/share/openmpi/1.2.4-gcc/help32/openmpi/doc -- Are the files
> located
> here used by the programs at run time? If so, this is fine. If not,
> they should be in /usr/share/doc (marked as %doc) instead.
Yes, they are used by the runtime. In particular, ompi_info --all will
read all the available options for the different modules that OpenMPI
actually has built. As the modules that a person builds is build time
configured, the OpenMPI architecture was set up so that each module
could just stick its relevant help info in these files, and the run time
help system will read the files as installed by the various modules.
> /usr/share/openmpi/1.2.4-gcc/man -- Why are these man pages placed
> here?
> Is it because of conflicts with other mpi implementations? If so,
> this
> is fine but see my question about environment-modules. (Note, I think
> you have to manually mark these as %doc since they don't live in the
> system %{_mandir})
Yes, they conflict with other MPI installations. In my current spec
file I don't mark them as %doc (you can't as far as I know, because the
%doc macro includes a step to copy the files into /usr/share/doc and as
such can't be used on anything *but* doc files), but I did have to
manually compress them in the %install section because they aren't in
the system mandir.
> /usr/share/openmpi/1.2.4-gcc/bin32
> /usr/share/openmpi/1.2.4-gcc/help32 -- Are these files arch specific?
> If so (even if they are text files but arch specific), they cannot go
> in
> /usr/share. Somewhere under %{_libdir}/openmpi would be better.
Yes. But more than just arch specific, they are openmpi version
specific and as I pointed out in my original explanation, users often
need multiple versions of openmpi installed. So, if I were to put the
binaries in /usr/bin, not only would I have to encode the arch, but also
the version into the binary name. This would then need to be aliased
via something like the alternatives system. I tried that. It was a
*horrible* mess to try and maintain and resulted in several broken
updates. So, putting the binaries for a specific arch/version into a
unique path and then using path manipulation to control use was much
cleaner. In addition, the help32/*-wrapper-data.txt files are used by
the devel environment to pull the default gcc compile/link flags for a
given arch.
> %{mode} in directories like /usr/share/openmpi/1.2.4-gcc/bin32 -- if
> we
> place these files in %{_libdir}, can we get rid of the %{mode} for
> them
> since the information will be present in the %{libdir} path?
Yes. This has been done in the latest spec file.
> /usr/share/openmpi/1.2.4-gcc/bin32/*
> /usr/lib/openmpi/1.2.4-gcc/openmpi/* -- Do these directories exist
> because of file Conflicts with other MPI implementations? If so, this
> seems basically okay but how are users supposed to access these
> programs? How are programs supposed to find the libraries? Would it
> be
> proper to package an enviroment-modules configuration for switching
> between the implementations?
Yes, there are file conflicts not only with other MPI implementations,
but different versions of the same MPI, and also the same MPI compiled
with different compilers.
In the current setup, access if via either mpi-selector (a glorified
alternatives setup that uses paths instead of links to solve the
problem) as well as environment-modules. When I bring the current stuff
over to Fedora, the mpi-selector setup will get dropped and only
environment-modules selection will be supported.
The libraries are found via an LD_LIBRARY_PATH setup created by either
the mpi-selector or environment-modules usage. The man pages are found
by placing the mandir and the bindir in the same top level directory.
In the case that <prefix>/bin/<command-name> has a matching
<prefix>/man/man?/<command-name>* man page, man automatically finds it
without having to manipulate the manpath or other settings.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
