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:
/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.
/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})
/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.
%{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?
/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?
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
