Doug Ledford wrote:
> 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.
>
If it's on your people.redhat.com account, could you post a link? The
index.html you have up doesn't have a link to this package.
> 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.
>
Cool. So that's fine.
>
>> /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.
So with environment-modules, this is fine too.
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.
>
This was untrue when I first learned to package but I haven't tested
recently. If you give a relative path to %doc it copies as you say. If
you give an absolute path to %doc, it just marks the file as being a doc
file.
>
>> /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.
Yep, agreed.
> 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.
As you found, alternatives is the wrong solution for this. These are
being used by users who might not be the system admin.
>> %{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.
>
So, with the exception of the arch-specific files in %{_datadir} which
has changed for the new release, this seems to be FHS-kosher to me. If
you can get me a link to the new package I can take a look and see if
the situation there is worse.
-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
